Oscar Rambla wrote:
> On Wednesday 14 January 2004 19:11, Graham Fawcett wrote:
>
>>Whether you try the code or not, it would be interesting to hear other
>>people's opinions of the Nevow templating system: is it black magic to be
>>shunned, the next best thing, or just YATS?
>
>
> YATS?
Sorry, Oscar: "yet another templating system".
> AMK wrote:
>
>>That's pretty cute. What are the pros and cons of this vs. PTL?
>>
>>* Full Nevow seems aimed at improving performance by pre-generating the
>> document, but this means you need support for callouts.
>> I'm not sure this optimization is worthwhile; is gluing together HTML
>> strings the bottleneck in any real applications?
>>* No need to remember to write ending tags. Advantage: Nevow.
>>* I'll bet you could make the classes enforce validity by checking
>> the child tags (so body[input()] would raise an exception).
>
>
> All these are good points.On the last, I feel really curious how the validity
> checking can be done. Tag specialization?, some parsing?
Tag specialization. Take the following expression, which is a list of
three empty items:
ul[li, li, li]
The ul's object's __getitem__ method is called, with a parameter of a
tuple, (li, li li). The ul object could have, for example, a '_contains'
attribute, listing names of valid elements that ul may contain.
Something like this could do the validation:
------------------------------------
class Tag:
....
def __getitem__(self, content):
....
if isinstance(content, tuple):
for element in content:
if not element.name in self._contains:
raise ValidationError, \
'<%s> not allowed in <%s>' % \
(element.name, self.name)
...
ul = Tag('ul')
ul._contains = ['li']
li = Tag('li')
...
------------------------------------
Since ul is an object (a prototype), we don't need to have a Tag
subclass; we could set the prototype's _contains attribute through some
other mechanism, perhaps based on a DTD. (I'm not tempted to include a
DTD parser, though, that seems like overkill. Perhaps one could just
define a dictionary:
html_4_constraints = {
'ol':['li'],
'ul':['li'],
....
}
and use it to initialize the prototypes.)
> About the first point:
>
> Matt Goodall wrote:
>
>
>>The context is also used to pass the tag, as defined by you in the
>>document tag tree, to the renderer. The renderer can ignore the tag and
>>return something new or do things like clear the tag tree and insert
>>something new, lookup parts of the tree and remove/replace/repeat them etc.
>
>
> I understand from this that Nowen pre-generates a tree representation.
> This is a different behaviour that could have its pros.
> I wonder if both behaviours could be compatible in some way without having to
> parse the result. I was not thinking in a DOM implementation. Instead, in a
> light one like PyRXP. Anyway a difficult task.
Well, if we can maintain the tree structure, and if you have access to
each node's name, attributes and children, then you should be able to
transform the tree. If I needed to do a lot of this kind of thing, I
would probably use another tool, but perhaps there are some simple,
common cases that we should facilitate. Some use-cases would be helpful.
I would hesitate to do /too/ much of this, or we will begin to
reinvent existing XML technologies.
>
> Also, I'd like it were easy ( I think it is with the current code) for
> programmer to provide their own specialized tags. I was thinking for example
> in tag.
Yes, it's very easy to add tags. Even XML namespaces are possible:
mytatg = Tag('foo:BAR')
mytag['hello']
would render to
hello
I didn't include a complete set of HTML tags in my implementation, but
it would be very easy to do so.
On a related point, we should discuss the namespace of the pre-defined
HTML tags. HTML includes tag names like 'table', 'option', 'button',
etc. that could easily conflict with names in our applications. Newow
uses lowercase tag names, but that increases the chance of namespace
collisions. Two possible ways to address this could be through
capitalizing the tag names:
mylist = UL[LI['an item']]
or recommend using an explicit namespace:
from tag_libraries import html
mylist = html.ul[html.li['an item']]
Neither is as attractive as the lowercase tags IMO, but both are safer.
Probably I would vote for capitalizing the tag names. (They could still
render in lowercase, e.g. TABLE = Tag('table') .)
-- Graham