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( mydomainobject.property,
> 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.
> 2. same for wiki syntax
Don't know. I never used something like that. We are more DB oriented
programmers.
> 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>
Flowscript again is good for that. JXG is not the right tool for that.
> 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.
> 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()}"/>
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.
> 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.
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...
>> 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.
lol.
> 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.
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.
Best Regards,
Antonio Gallardo
