RE: [Zope] Proposal: Include tino's patched <dtml-in> in future Z ope
Is that not a standard problem in the Zope context?
If you access any object via acquisition or the DTML namespace, then the definition of a new property can break code: the property may be retrieved rather than an object formerly acquired, looked up deeper in the namespace.
Yes. Both of these mechanisms can only be made robust by controlling which namespace will staisfy namespace search. That means not relying on the fact that a name will not be found in an 'uncontrolled' namespace. I posted a patch on this list a while back, which used a __getattr__ hook to list all the names which were being looked up, but not found, in the zope root object. The output is listed at http://www.zope.org/Members/htrd/names. Try creating a property under one of those names and see what breaks. (this list was created with 2.2.x. several patches to fix such issues have been merged since then) There are several solutions to this problem: for dtml, switch to a different language for any non-trivial logic. for acquisition, 2.3.0 introduced a __replaceable__ attribute that adds protection to a name inside a containment heirarchy. This is a good start, but not yet a total solution.
Hi Toby, Toby Dickenson wrote:
Is that not a standard problem in the Zope context?
If you access any object via acquisition or the DTML namespace, then the definition of a new property can break code: the property may be retrieved rather than an object formerly acquired, looked up deeper in the namespace.
Yes.
Both of these mechanisms can only be made robust by controlling which namespace will staisfy namespace search. That means not relying on the fact that a name will not be found in an 'uncontrolled' namespace.
Oh, there is such solution already. One can (and I encourrage to) use <dtml-with ... only> </dtml-with>
I posted a patch on this list a while back, which used a __getattr__ hook to list all the names which were being looked up, but not found, in the zope root object. The output is listed at http://www.zope.org/Members/htrd/names. Try creating a property under one of those names and see what breaks.
(this list was created with 2.2.x. several patches to fix such issues have been merged since then)
There are several solutions to this problem:
for dtml, switch to a different language for any non-trivial logic.
How does it help this "property covers object" problem better then with dtml? Please keep in mind this replacement is thought to simplyfy writing and teaching of writing of dtml. DTML has its strengs in fast prototyping and easy integration with content. As I said already, I hate content in python programs and scripts. There would be another, yet better solution using ZDOM to provide high structurized content and external manipulation therof with python. Unfortunately we are far away from this. For DTML you cant save the namespace anymore ;) There are a lot of pollutions already. Did you have a closer look at ZSQL-Methods? They deliver many aliases with recordsets. I myself had no problem with removing all unhandy hypenation variables at once, leeving the namespace almost as clean as it is now ;) But surely it would break all old code. Regards Tino
Tino Wildenhain writes:
Oh, there is such solution already. One can (and I encourrage to) use <dtml-with ... only> </dtml-with> "dtml-with ... only" will not help you, at least not alone. It does not disable acquisition.
Dieter
Dieter Maurer wrote:
Tino Wildenhain writes:
Oh, there is such solution already. One can (and I encourrage to) use <dtml-with ... only> </dtml-with> "dtml-with ... only" will not help you, at least not alone. It does not disable acquisition.
<dtml-with "x.aq_explicit" only> ...might do it ;-) cheers, Chris
participants (4)
-
Chris Withers -
Dieter Maurer -
Tino Wildenhain -
Toby Dickenson