On Monday 19 January 2004 08:27, Graham Fawcett wrote:
> > YATS?
>
> Sorry, Oscar: "yet another templating system".
Despite my poor english :-( , this time I'd already guess its meaning.
> > 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.)
>
Also, you could call a validator method for each content element. So, a
programer could supply his version to contrast with the schema or DTD he
likes.
> > 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.
>
I didn't pretend you to do it , in any way. Maintain the tree structure would
be enough for me. If I needed to do a lot of things I could translate it to a
well-proven XML tool. Sorry but I don't see the way to maintain it with the
current version.
> 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') .)
>
Also, user, been advised, could provide its prefered name with as:
from tag_libraries.html import ul as UL, li as Li ...etc
-Oscar