cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: why JXTG sucks? was: FreeMarker integration
Date Tue, 10 Aug 2004 09:59:41 GMT
Antonio Gallardo wrote:

> Leszek Gawron dijo:
>>I have implemented only a few small projects using jxtg and found some
>>live examples of these limitations:
>>1. you cannot parse string from your model as xml, had do use session
>>    hacks to do that ( put flowscript function into session, use it via
>>    macro in jxtg):
>>    function xmlProducer( value, consumer ) {}
>>    cocoon.session.setAttribute( "xmlProducer", xmlProducer );
>>    in jxtg you do:
>>    ${cocoon.session.xmlFormatter(,
>>                                   cocoon.consumer )}
>>    or create a macro to hide this awful syntax.
> We also use session and this kind of stuff is prepared on the flow script
> or a helper java class. As I told before JXG just read data. It was not
> intended to be forced this way. Bussiness model stuff must be separated.
a template language user should not be forced to create helper classes 
and if he/she needs a particular specific functionality it should be 
plugged into and not used explicitly.

>>2. same for wiki syntax
> Don't know. I never used something like that. We are more DB oriented
> programmers.
Some of my entities have "description" property which I allow users to 
will in with wiki markup so it is nicely rendered on the page.

>>3. I had to write a special class to create links that hold all current
>>    request parameters apart from selected ones (i.e. to reload the same
>>    page under different locale).
>>    then use it like <a href="${
>>    LinkFormatter.getLinkWithAllReqParamsExcept(
>>                          'locale'}&amp;locale=en">Switch to english</a>
> Flowscript again is good for that. JXG is not the right tool for that.
Flowscript is a controller, controller should not perform data 
formatting. it is view specific functionality. I should be able to 
switch jxtemplate to another one simply changing the view uri in 
cocoon.sendPage. If that forces me to refine my controller although the 
new view uses the same data - it is SoC break.

>>4. There is no jx:attribute functionality so if you want to insert
>>    attributes conditionally you have to duplicate the WHOLE node (which
>>    might be huge)
> Flow script job again.
Not true. View is the one to decide if a piece of data should be 
rendered as tag or attribute. You use it this way because you have to 
overcome JXTG's lack of that feature.
>>you are not able to plug any of these "extensions" (hacks should be
>>written) to view once and for all so you end up setting your session
>>attribute for every view that might use it and importing a macros file
>>in the same jx template. FreeMarker allows to configure so called
>>"shared variables" that provide additional functionality. You could
>>subclass a FreeMarkerGenerator to register any of your additional
>>functionality without performing such ugly hacks.
>>All this processing is VIEW specific only. I should not be forced to
>>create another bizData data representation for every view I come to
>>implement. This breaks SoC as I might want to create more than one view
>>of the same data. If I followed your proposal I would have to end up
>>implementing several bizData representations. This is half a step ahead
>>from implementing a pure xml generator - try to do that for every view
>>in your project.In JXTG you can break SoC whereever you like. Browse
>>cocoon examples and mailing list for constructs like:
>><jx:set var="ignore" value="${performSomeOperationsHere}"/>
>>worse :
>><jx:set var="ignore"
> I never needed something like that and we present sometimes the data in
> diferents formats and order. Even sometimes we need to skip some pages
> based on the user input, a simple <jx:if> is enough to make the job done:
> <jx:if test="${ignore == 'false'}">
> ...
> </jx:if>
> The ignore variable is part of the bizdata that comes from the flowscript.
> I know the line between what is VIEW and what is MODEL is very thin. But
> we prefer to let the MODEL decide what the user will see. For us JXG is a
> template generator, nothing more nor less.
I am not talking about the need. I also never needed this. But if you 
exposed your jx template to be edited by user online he/she could inject 
such code and bring your server down. I was amazed of jroller 
functionality that allows user to access the template of every part of 
his/her blog template to be edited. One has a library of macros to 
access blog data model. It's completely up to you how you present it. 
Noone needs to alter the data model (which should be entities straight 
from database not altered at all) if user prepares a new view for his data.

>>>I think velocity stoped to be developed (as was posted in the provided
>>>link) because it stoped to be interesting. People found another ways to
>>>make the job done. I think mainly because XML was on the scene. But
>>>velocity was a very nice language at the time, trying to provide HTML
>>>dynamic building features. Currently, I saw both (velocity and
>>>as some kind of JSP, ASP, PHP, etc. I think we (cocoon) are beyond this
>>>technologies while we still use them for some special cases. Note I am
>>>telling they are useless.
There is one big difference between jsp, asp, php and the templating 
languages: templating languages does not allow injecting program code 
into template. Velocity is far closer to JXTG than to XSP, JSP

>>We are not "beyond" as we have no powerful templating language. JXTG
>>offers 10% of functionality of FreeMarker or Velocity.
> The point is we are moving away of this kind of things. This is what I
> think. We try to keep clean sources. A mess of VIEW+MODEL is not good and
> that is what we got using velocity...
how do you mess your model and view with velocity? I think it's even 
kept cleaner in Velocity as you cannot execute external code with such 
ease as in JXTG. Even the opposite: right now you are messing your data 
model with presentation information. That is what you said yourself.

> Well, as I told you before, if you feel that FreeMaker feel the gap to
> you, it is OK. Please create the generator and show us. Really as I told
> before, I am not against it. I am +1 to see FreeMaker in action.
I will create a trivial and stupid implementation in a few days - just 
to evaluate freemarker features. We'll see.

Leszek Gawron                            

View raw message