cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: [Design] JXTG 2.0 (Just say you're sorry!)
Date Fri, 03 Dec 2004 10:38:41 GMT
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
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.

>> 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.

<snip what="even more esql pros and cons"/>

my regards
-- 
Leszek Gawron                                      lgawron@mobilebox.pl
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


Mime
View raw message