[Zope] Proposal: Include tino's patched <dtml-in> in future Zope

[Tino Wildenhain]

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