Web templating/db tool with best designer/coder separation?

[Stefan Franke]

On 2 Jul 2002 13:28:53 -0700, paul at boddie.net (Paul Boddie) wrote:
[...]

>This is what Enhydra's XMLC does, and one uses a DOM-like API to
>access the elements marked in this way in the document.

Thank, Paul, for this interesting reference!

 * * * 

On Wed, 03 Jul 2002 11:11:02 +0100, Richie <rjh at cyberscience.com> wrote:
[...]

>The biggest problem I can see is that I'm using object attributes to
>represent both HTML tag attributes and child objects.  So 'form.name'
>could refer to an attribute of the <form> tag or to an input control on
>the form.

I don't think this really is a big problem. A HTML document has to be
checked only once if an Id of a son element collides with one of its
attributes (e.g. when modified as a Zope document). 

During processing, only the add_attribute() function has to check for 
son elements of the same name accordingly.

Name collisions could also be avoided with naming conventions or by 
allowing structured names for elements itself (id="attr.color")

>Note that all these classes, Template.Table, Template.Form, etc. etc.,
>would probably be created on the fly - there wouldn't really be a chunk 
>of code in the Template module for every HTML tag.

Here I don't (yet) see the advantage of having different classes mirroring 
the different HTML tags. Ok, the table object in your example offers add()
and remove() methods, OTOH ZPT shows us that a set of uniform operations
replacement operations is sufficient.

The XMLC Paul mentioned seems to use a single class for this as well 
(org.enhydra.xml.xmlc.html.HTMLObject, as far as I interpret 
http://webreference.com/xml/column23/3.html).

I would try to keep things even more simple: Is there really a need for
a DOM-like access where each tag and sub-tag of interest has to be 
tree-like identified? If there's only one place where substitution
should happen, it's not necessary to mark more than one tag, even if
this one is deeply nested.

Thus, the document tree would fall apart into a forest of sparse subtrees,
each of which usually not more than 2 or 3 levels deep. This help a lot 
to keep the addressing simple, and allows more abstration between the HTML
documents and the templating scripts - in case the same script is used
with multiple documents, only the 'abstract' document structured, as
given by the identified tags, has to match.

In a perfect world, we had even two layers of template substitutions: A
'low-level' one based one a Python API (like yours above), and a higher
level one that specifies the substitutions in a more condensed way,
(a little context-specific, mayve Quixote-like language).

Since the latter one is restricted to a few operations, it could be 
pre-compiled together with the HTML documents for maximum performance.

Stefan