[Zope] Zope needs this (and Dynamo has it)

[Martijn Faassen]

Shalabh Chaturvedi wrote:
> Martijn Faassen wrote:
> 
> > Still, a simple variety of DTML would be nice. Currently you can
> > successfully use a subset of DTML, which almost has no arcaneness but
> > is still very powerful. PythonMethods will help even more there. Still,
> > DTML allows too much, so it's too easy to move into the arcane domain. Also
> > some of its powerful features have the side effect that some of the simple
> > features look too complex.
[snip new language]
> I don't think a new syntax should be brought about. There are too many things
> to learn already, it will only add to the confusion.

That's true, but that shouldn't hold us back indefinitely; some things are
can only be improved after a while if they're redesigned from scratch, 
otherwise the back-compatibility issues become too complicated. I don't know
if DTML is at this state though, and any new language proposal should be 
something to consider for the (very) long term.

> I do agree that dtml is complex and something needs to be done about it.
> Probably a subset of the current dtml itself - with minimal additions which
> make somethings easy - would be good.
> 
> Also (if this is seriously being considered)

I don't think anyone's serious yet. :)

> I would favour for a somewhat
> different paradigm:
> 
> Instead of:
> > <var object="layout.table_header"/>
> > <in object="get_above_age" arguments="age">
> > <var object="myrecord" arguments="in_item"/>
> > </in>
> > <var object="layout.table_footer"/>
> 
> We could have:
> <dtml-var object="layout.table">
> <param name="datasource" value="get_above_age">
> <param name="columns" value="Name,Age">
> </dtml-var>
> 
> The advantage here is that:
>    o   One logical presentation element (a table) is one element in dtml code.

But you lose some flexibility in defining table headers and footers;
you have to be careful your simple language becomes too rigid, making
too many assumptions.

>    o   One-to-one relation is possible between the code and any GUI entity
>         being used to design (think ZStudio). This means the layout.table can
>         be one icon that is dropped into a design view and it's parameters
>         specifed through some fancy widget. 
>         Also when the code is stored and reloaded, it would still be
>         possible to display the same GUI entity in the design view and it's
>         parameters would be editable.

Hm, what you're proposing is some higher level object (a product) that
does tables (in this case). That would in fact be rather neat.. Our simple
glue language could become extremely simple if we have sufficient higher
level components, and if it's easy enough to code up your own components.

I'm doing something like that for web forms in my ZFormulator product.

> Discussions on the above have taken place on the ptk and zope-moz lists.

Okay, this kind of discussion probably belongs on another list, I agree. :)

Regards,

Martijn