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.
but this is only a "model traversal" language. JXTG offers very small functionality in: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.
- 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'}&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.
We are not "beyond" as we have no powerful templating language. JXTG offers 10% of functionality of FreeMarker or Velocity.
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.
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 encodedI 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 [EMAIL PROTECTED]
