cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonas Ekstedt <>
Subject Re: Implementation of a tag attribute language
Date Sun, 05 Dec 2004 16:56:32 GMT
On Sun, 5 Dec 2004, Daniel Fagerstrom wrote:

> > <table>
> >   <tr tal:do="forEach(listOfBeans)">
> >     <td>${it.beanProperty1}</td>
> >     <td>${it.beanProperty2}</td>
> >   </tr>
> > </table>
> >
> > => (ignoring whitespace nodes) =>
> >
> > PlainElementToken  localName="table"
> > TALToken           localName="tr", do="forEach(listOfBeans)"
> > PlainElementToken  localName="td"
> > ExpressionToken    expression="it.beanProperty1"
> > PlainElementToken  localName="td"
> > ExpressionToken    expression="it.beanProperty2"
> Something in that direction. I would prefer this:
> PlainElementToken  localName="table"
> TALToken           do="forEach(listOfBeans)"
> PlainElementToken  localName="tr"
> PlainElementToken  localName="td"
> ExpressionToken    expression="it.beanProperty1"
> PlainElementToken  localName="td"
> ExpressionToken    expression="it.beanProperty2"
> It gives the TALToken access to its enclosing element (with the tal:do
> attribute removed). It also generalizes to multiple directives in an
> natural way:
> <tr tal:do="forEach(listOfBeans);if(...)">
> ...
> =>
> PlainElementToken  localName="table"
> TALToken           do="forEach(listOfBeans)"
> TALToken           do="if(...)"
> PlainElementToken  localName="tr"
> ...
> Where the "forEach" TALToken invoke the "if" TALToken while executing
> invokeBody, which in turn can invoke the "tr" PlainElementToken. The
> "getAttributes" method in the TALToken class just calls the
> "getAttributes" method in its child.

Yeah, that's a better idea. We could even go a step further:

PlainElementToken  localName="table"
ForEachTALToken    parameter[0]="listOfBeans"
IfTALToken         parameter[0]="a < b"
PlainElementToken  localName="tr"

It shouldn't however, as you say, be possible to add custom TALTokens.


> By having a standardized way to pass arguments to both attribute and tag
> driven directives they can share implementation.

I'd say they're sufficiently different to warrant separate
implementations. A TALToken parameter can be stored
as a single Expression object whereas a TagToken attribute is either a
CharactersToken or an ExpressionToken (or even a mix of both). There are
probably other differences as well. Also there won't be all that many
TALTokens so the code duplication will be negligble.


> BTW: I think that your implementation of the script and token structure
> is quite cool in the way that we get the tree structure nearly for free
> and it also seem quite space efficient. But on the other hand I believe
> that the explicit handling data structure implementation details spreads
> to much to other parts of the code. Which will make the implementation
> unecesarilly complex.
> I would prefer to refactor the code so that element, attribute and
> character tokens are responsible for their children with methods like
> "addChild(...)", "addAttribute(...)", "getAttributeItterator()" etc.
> This can be implemented efficiently by e.g. using single linked lists of
>   tokens where each token has a reference to the next token.
> We can squeze out the last few bits of space efficency later if needed,
> but at this stage in the project I think we should strive for simplicity.
> WDYT, am I missing something? Do you have anything against if I refactor
> the code in the direction I described above?

What you propose is certainly a better solution. I always felt
uneased by getStart(), getStartBody() and the likes. Won't be able to help
unfortunately as exams are looming.

Cheers Jonas

View raw message