[Zope-Moz] Templates anyone?

[Shalabh Chaturvedi]

[RH] is Rik Hoekstra
[SC] is Shalabh Chaturvedi

[SC::]
> Then it is the same I am thinking of doing with dtml. But I feel doing this
> should be easier than writing python and using something like HTMLgen.

[RH::]
> Hm, I used HTMLgen before Zope in cgi, and it was not complicated at all. It
> involved some python, but then again from a simple external method it will
> involve more than (say) three lines or so. All the parameter things are
> already there or could be added easily with a subclass.
> The big advantage is you get a series of containers with objects which you
> can move around and add things to. They are arguably more easy to manage
> than template like things that are sequential (if that's English). But then
> again, this idea may have drawbacks I'm not aware of.

HTMLgen could be easy and all, no doubt. It is probably even
more powerful than what is required for just creating dtml
from 'patterns'.

What I am concerned about is that for a user wanting to use 
this, there would be this 'something' extra he has to learn.
I feel it's important to have as little new learning required as
possible. Ideally plain dtml users should be able to go and
create their own patterns and use them.

I was just thinking of "dtml producing dtml". Consider:

<dtml-in columnNames>
   <td> [dtml-var <dtml-var id>]
</dtml-in>

For columnNames = ['Name','Age'],
this would normally produce:

<td> [dtml-var Name]
<td> [dtml-var Age]

When evaluated as a pattern, it could produce:

<td> <dtml-var Name>
<td> <dtml-var Age>

The above _could_ be _one_ way to do the first evaluation 
(Pattern->DTML). This would have it's pitfalls, I'm sure, but 
they have to weighed against the advantages. One big 
advantage I see is it would be easy to do for dtml users.

[RH::]
> > SO much for inserting new elements in templates, but what are your
> > thoughts
> > about maintaining/editing such object based pages? Should they be
> > rendered/partially rendered. If they're rendered, how do you provide a
> > general mechanism that keeps them from being edited? How does the editor
> > know where the object boundaries are in a template? How does Zope know
> > which
> > parts to update and which not?

[SC::] 
> Again I cannot answer fully, simply because these
> things have yet to be thought out.

[RH::] 
> That's OK, it will bring us further. Actually I only have a faint idea about
> how implementation could be accomplished. I read your GUI document at the
> ZopeMozilla site and I thought it was going more or less in the same
> direction.

I don't know how important the dichotomy problem you mentioned
is to the community but I think the present scheme, although providing
great flexibility, allows for a complete hotchpotch website design.
Almost everything is done in a DTMLDocument (or Method):
 - Visible Pages
 - Updates to persistent objects
 - Control Flow depending on state and user interaction
 - etc.

As a result, users might create a number of DTMLDocs which
lie on top of one another, each putting in some 'visible' element, 
doing some lookup, control flow etc.

It might be more productive provide the user a wider range
of building blocks (than just DTMLDoc), that guide him to 
a more modular and better architected website. This might 
even make it easier to determine what objects are to 
rendered, partially-rendered etc and when.


[SC::]
> But I can say:
>       (...snipped...) 
>

[RH::]
> Sounds good, useful and doable. Of course this only works for real standard
> patterns. 

Depends on what you mean by real standard patterns.
Every user might have some pattern he uses often and
he wants to reuse. Some patterns might be integrated
with the Studio (or even PTK?).

[RH::]
>              You would still be left with custom dtml written by people. 

Yes. Any solutions you have in mind?

[RH::]
>                          On the
> other hand, it seems a good idea to move as many dtml out of actual
> documents as you can. This would also help in getting different views of
> templates.

Cheers,
Shalabh