cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject why JXTG sucks? was: FreeMarker integration
Date Tue, 10 Aug 2004 09:13:21 GMT
Antonio Gallardo wrote:
> Hi Lezsek:
> 
> I will talk about my own experience. We already build 2 fairly
> semi-complex forms intensive applications with CForms + JX Template
> Generator. The idea is that JXG is used only for some special view
> purposes. You "prepare" the data on a java class and JXT just show them.
> We also use it to build reports.
Me too and I really hate it when hitting the wall and starting to hack.

> I think this was the idea when JXG born. JXT was not designed as a
> repleacement for velocity. In fact the problem with velocity and similars
> is the mixed concerns and for this reasons JXT is so simple it gives you
> all the necesary tools for the view job. JXT has inside a mix of 2
> powerful language.
but this is only a "model traversal" language. JXTG offers very small 
functionality in:
  - control statements
  - data formatting
  - extendability (via taglibs - jx:macro sometimes fails to deliver 
functionality as it is limited itself)

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( mydomainobject.property,
                                   cocoon.consumer )}
    or create a macro to hide this awful syntax.

2. same for wiki syntax
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="${Packages.com.mobilebox.utils.
    LinkFormatter.getLinkWithAllReqParamsExcept(
                          'locale'}&amp;locale=en">Switch to english</a>

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)

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" 
value="${Packages.com.mycompany.ClassThatWillMessThingsUp.doIt()}"/>

Because of this you could not provide your application with the 
functionality that your users define parts of the application interface 
by editing or providing own templates. This could be the ultimate threat 
to your app (especially the open source one as users would know exactly 
what code to call to mess up). I wonder if they could bring the whole 
system down by simple ${System.exit( 0 )} :))). It would be enough that 
method that does this is reachable in classpath.

FreeMarker does not allow that as it wraps data model at the runtime and 
you are not allowed to call anything outside of it.

> 
> 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 freemaker)
> 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 not
> telling they are useless.
We are not "beyond" as we have no powerful templating language. JXTG 
offers 10% of functionality of FreeMarker or Velocity.

> All in all, based on the cocoon nature, I think we can also create a
> FreeMaker Generator and use it in Cocoon. I already don't saw the license,
> we need to check them if is compatible with AL 2.0.
its BSD, means - compliant.

Although maybe discontinued Velocity still is the top of the templating 
languages used for view generation in web applications. Almost all web 
frameworks use it. Like with democracy: sucks but there is nothing 
better right now.

One of JXTG pros is that every value from data model gets automaticaly 
converted to a "xml safe string" (entities encoded). In FreeMarker it's 
a little bit more to do but still the solution exists (there is no such 
in Velocity):

${myObject.value?xml} outputs the value xml encoded

I forgot about one more templating possibility: XSLT, but this sucks 
too. It is fine only for "common look transformations" (site2html.xsl 
that everybody uses - including me). To stop arguments about that - I 
mean that in terms of web application, not publishing.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl

Mime
View raw message