First of all, I would like to apologize for my inflammatory tone. My ire was directed toward the proposal, not the people proposing it. That said, I went over the top. Too many arguments with young Earth Creationists lately and it spilled over into my writing on this list. To Leszek in particular, I am sorry for the reckless criticism. To Stefano, I'm sorry for putting you in the position of agreeing with someone who did not conduct himself well.No hard feelings Mr. Bond :). I am not even half experienced as you all are and participating in cocoon development is a pure pleasure - even listening to criticism. I learn from it A LOT.
One thing only to clarify: I am to blame for the commit. But I am not the creator of the base cocoon-block-template implementation. I just cleaned up Jonas Ekstedt's work - the credit for the effort goes to him.
But I have seen taglibs go terribly wrong in real-world situations far more often than they've worked out. I'm a firm believer in defining the interface first through use cases and only afterward discussing the implementation/design. Granted, my primary experience with taglibs is JSP's flavor. That may have colored my view of the technology unfairly in general.
As I have said in other post: The taglib word may be very dangerous for whole effort here. I think about this as of the renderers of the model with no side effects. As for other taglibs - we should not host them in cocoon distribution to give users bad impression of the direction they should follow.
ESQL should not be implemented in new template. It has too much side effect and is a powerful weapon in anti-template camp hands' :)
Granted, but citing that JXTG is a monolithic headache doesn't mean that the deconstruction must be total. Modularization can happen in degrees. For example, just by making a common interface between lookup libraries (JXPath, JEXL, etc.) would remove HUGE amounts of code from JXTG. The switch back and forth between object lookup mechanisms is probably the biggest reason for JXTG's complexity.
Sure. But JXTG mainly suffers from the lack of extendibility. You can see a lot of JXTG hacks in cocoon samples even right now.
There are two hacks that I use for JXTG all the time:
- use a external function (static method, flowscript function) in jxtg
that accepts a bean and xml consumer to generate sax events:
${Packages.com.something.Utils.prettyPrint( bean.value,
cocoon.consumer )}- use a hash map and a set of macros to handle dynamic tags:
<jx:set var="tags" value="${java.util.HashMap()}"/>
<jx:macro name="dynamic-tag">
<jx:parameter name="id"/>
<jx:set var="ignored" value="${tags.put(id, macro.body)}"/>
</jx:macro>
declare a dynamic tag:
<dynamic-tag id="resultRow">
<td><a
href="/nTer/projectDetails.do?projectId=${project.id}"><b>${project.name}</b></a></td>
<td>
<radeox-string value="${project.description}"/>
</td>
</dynamic-tag>
later on use it in macro for example:
<jx:forEach var="${item}" items="${items}" varStatus="status">
<colouredRow rowNo="${status.index}" odd="floralwhite" even="#eaeaea">
<jx:eval select="${tags.resultRow}"/>
</colouredRow>
</jx:forEach>
*I just found that we promote this hack on cocoon site*: http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#eval
Both cases indicate that JXTG allows for a great amount of dirty tricks. The users will use them as long as we do not give them a better tool.
I'm a big proponent of "make the better decision easier than the worse decision." Quick and dirty, ESQL works. For limited obscure cases, ESQL is great. But the better decision would be to use object mapping (Hibernate, JDO, et al.) and CForms in Flow. Tag libraries seem to me to promote an excessive shift of logic to the templating language instead of in the backend data processing architecture. Not forcing but encouraging people to move as much logic as possible to Flow seems like it would allow more flexibility while remaining more maintainable and clear. "Clear" not in the sense that the individual template and app is understandable but that the hundredth template and app is understandable.The user should be informed of the danger of mixing the concerns. But it's his/hers choice to break the rules. Cocoon should promote good practices not enforce them.
The whole conversation got totally polluted with ESQL. Templating is very useful for CForms dependent on model data. I.e. render the delete button only if model says you are allowed to invoke that action.For those of us who use CForms it is very convenient to be able to use the template tags together with JXTG constructs.
So we need a template generator with three sets of tags "jx:", "esql:" and "ft:" thats it.
We also discused how to use a separate conversion layer to remove the need for formating constructs from the template layer.
I'm not following. If you are using CForms (and thus Flow), why would you make template calls to a database? Why not do the persistence logic in Flow right next to where you are sending and receiving form data? From a logical point of view, I would think that these would be better served next to one another.
<snip what="even more esql pros and cons"/>
my regards -- Leszek Gawron [EMAIL PROTECTED] Project Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
