Miles Elam wrote:
> 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
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:
- use a hash map and a set of macros to handle dynamic tags:
declare a dynamic tag:
later on use it in macro for example:
*I just found that we promote this hack on cocoon site*:
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.
>> 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.
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.
Leszek Gawron email@example.com
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