Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Miles Elam wrote:
<snip/>
<friend jx:context="${people}" jx:test="${name != 'Mean Mike'}">${name}</friend>
<snip/>
Ok. My conclusion about this is twofold: - taglibgs should be triggered by attributes and not only by elements,
It's ok with me. Question is how do we interprete the construction above. From commons sense we can infer that the test for the name should be performed for each person in th sequence of people.
Yes. Actually, it would be clearer if written something like
<friend jx:forEach="${people}" jx:if="${name != 'Mean Mike'}">${name}</friend>
where attributes are actually the same as tag names.
This of course works only for tags having a single attribute.
We could maybe infer the same thing by studying the input data structure. What if I want a double loop over two sets?
You cannot using tags-as-attributes as there cannot be two attributes with the same name. In that case, you either use tags-as-elements, or use some container element.
Any ideas about how to implement it? What would jx:context and jx:people correspond to? If we just allow one "programatic" attribute per element, the code connected to it could be allowed to do whatever it want to when its parent element is called but its more complicated when there are several "programatic" attributes, how do we control their relative nesting.
IMO, the resolution of tags-as-attributes should follow a priority order that will be built into the taglib. That can be implemented using a filter that transforms tags-as-attributes into tags-as-elements in a predefined order.
There's still a problem however, when tags-as-attributes coming from several taglibs exist on a single element, as we must know the relative order of the taglibs.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
