You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leszek Gawron <lg...@mobilebox.pl> on 2004/08/10 11:13:21 UTC
why JXTG sucks? was: FreeMarker integration
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'}&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
Re: why JXTG sucks? was: FreeMarker integration
Posted by Tony Collen <co...@umn.edu>.
Leszek Gawron wrote:
> Joerg Heinicke wrote:
>
>> Why JXTG sucks? Because it's to powerful!
>>
>> http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
>> (It's not the first time that it is posted here.)
<snip>
>> Jörg
>
>
> I'll read the document and have more comments tomorrow.
>
Browsing over the PDF, ahh, "recusively-enumerable", turing machines,
my brain is about to explode, only because I'm doing this stuff in
school *right now*.
More comments later,
Tony
Re: why JXTG sucks? was: FreeMarker integration
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Joerg Heinicke wrote:
> Why JXTG sucks? Because it's to powerful!
>
> http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
> (It's not the first time that it is posted here.)
>
> rules:
> view cannot modify the model
> view cannot perform computations upon dependent data values
> view cannot compare dependent data values
> view cannot make data type assumptions
> data from the model must not contain display or layout information
assume you have a collection of Projects. Each project has a
project.description property. This property contains a string that can
be parsed by a wiki parser and generate html out of it. How would you
implement that. Assume that your controller does NOT know what string
properties should be wikified as there are hundreds of this kind of
properties and you also have several orthogonal views which query
different model parts.
if the view cannot perform computations you cannot put it into view
layer as some kind of macro
if the data cannot contain display or layout information you shouldn't
preformat all your project.description properties. Also it is plainly
stupid to provide the view with two versions or each property: raw and
formatter as the third formatter might come to action. what then ?
>
> FreeMaker is also mentioned in the document - as example for highest
> entanglement index.
>
> Jörg
I'll read the document and have more comments tomorrow.
--
Leszek Gawron lgawron@mobilebox.pl
Re: why JXTG sucks? was: FreeMarker integration
Posted by Joerg Heinicke <jo...@gmx.de>.
Why JXTG sucks? Because it's to powerful!
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
(It's not the first time that it is posted here.)
rules:
view cannot modify the model
view cannot perform computations upon dependent data values
view cannot compare dependent data values
view cannot make data type assumptions
data from the model must not contain display or layout information
FreeMaker is also mentioned in the document - as example for highest
entanglement index.
Jörg
Re: why JXTG sucks? was: FreeMarker integration
Posted by Nuno Santos <ns...@electroplus.pt>.
Just "Jelly"!
It has all functionality that JXTG gives you, plus the fact that you can
build your own tags either as classes or as macros!
On Tue, 2004-08-10 at 16:14, Antonio Gallardo wrote:
> Nuno Santos dijo:
> > JXTG is a nice templating tool, but very limited! Why should we be stuck
> > to it if we have a more powerfull templating stuck in the scratchpad?
>
> Please, can explain more what we have there? Just curious.
>
> Best Regards,
>
> Antonio Gallardo
--
Nuno Santos <ns...@electroplus.pt>
Electroplus, lda
Re: why JXTG sucks? was: FreeMarker integration
Posted by Antonio Gallardo <ag...@agssa.net>.
Nuno Santos dijo:
> JXTG is a nice templating tool, but very limited! Why should we be stuck
> to it if we have a more powerfull templating stuck in the scratchpad?
Please, can explain more what we have there? Just curious.
Best Regards,
Antonio Gallardo
Re: why JXTG sucks? was: FreeMarker integration
Posted by Nuno Santos <ns...@electroplus.pt>.
JXTG is a nice templating tool, but very limited! Why should we be stuck
to it if we have a more powerfull templating stuck in the scratchpad?
--
Nuno Santos <ns...@electroplus.pt>
Electroplus, lda
Re: why JXTG sucks? was: FreeMarker integration
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> Ugo Cei wrote:
>
>> Il giorno 10/ago/04, alle 11:13, Leszek Gawron ha scritto:
>>
>>> 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):
>>
>>
>>
>> I don't think it's the view's responsibility to parse XML. Parse it
>> in the flowscript and pass the resulting DOM to the view. You can do
>> that in bizData without using the session at all.
>>
>>>
>>> 2. same for wiki syntax
>>
>>
>>
>> Same as above.
>>
>> WRT your other points, I agree that the JXTG is somewhat limiited and
>> clumsy, but don't try to have it do more than what it should,
>> otherwise you're back to XSP.
>>
>> Ugo
>>
> I see this functionality on the same level as : jx:formatDate,
> jx:formatNumber
>
> I know you are using hibernate in your projects. Assume you have
> lazily loaded, big data model passed to your view. some of the
> properties in model are strings. At view level, when you traverse your
> collections you want pretty print some of your model properties
> instead of doing only ${object.property}. The property might be at any
> level of your data model. Moreover - if you have lazy loading you can
> provide your every view with the same huuuge data model so the view
> decides which part to use and present.
>
> From this point of view the pretty printer is a part of templating
> language. Controller should not know nothing about that as this is a
> part of view rendering. If you wanted to pretty print your properties
> in flowscript you would have to provide:
> a) a wrapper for you entity so it can pretty print your data. This
> will break your lazy loading and break the whole
> one-big-model-multi-views idea
>
> b) insert pretty printing code in your entity itself. This forces
> code duplication and breaks separation of concerns. I do not want my
> entities expose a dependency to some kind of wiki parsing library,
> xml formatting library, number formatting library,
> some-very-sophisticated library.
>
>
>
IMHO the missing features in JX are the attribute problem and that you
can't plug in your own languages. Most of the other problems you
describe should be handled by a framework like CocoonForms.
--
Reinhard
Re: why JXTG sucks? was: FreeMarker integration
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Ugo Cei wrote:
> Il giorno 10/ago/04, alle 11:13, Leszek Gawron ha scritto:
>
>> 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):
>
>
> I don't think it's the view's responsibility to parse XML. Parse it in
> the flowscript and pass the resulting DOM to the view. You can do that
> in bizData without using the session at all.
>
>>
>> 2. same for wiki syntax
>
>
> Same as above.
>
> WRT your other points, I agree that the JXTG is somewhat limiited and
> clumsy, but don't try to have it do more than what it should, otherwise
> you're back to XSP.
>
> Ugo
>
I see this functionality on the same level as : jx:formatDate,
jx:formatNumber
I know you are using hibernate in your projects. Assume you have lazily
loaded, big data model passed to your view. some of the properties in
model are strings. At view level, when you traverse your collections you
want pretty print some of your model properties instead of doing only
${object.property}. The property might be at any level of your data
model. Moreover - if you have lazy loading you can provide your every
view with the same huuuge data model so the view decides which part to
use and present.
From this point of view the pretty printer is a part of templating
language. Controller should not know nothing about that as this is a
part of view rendering. If you wanted to pretty print your properties in
flowscript you would have to provide:
a) a wrapper for you entity so it can pretty print your data. This
will break your lazy loading and break the whole
one-big-model-multi-views idea
b) insert pretty printing code in your entity itself. This forces code
duplication and breaks separation of concerns. I do not want my entities
expose a dependency to some kind of wiki parsing library, xml
formatting library, number formatting library, some-very-sophisticated
library.
--
Leszek Gawron lgawron@mobilebox.pl
Re: why JXTG sucks? was: FreeMarker integration
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 10/ago/04, alle 11:13, Leszek Gawron ha scritto:
> 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):
I don't think it's the view's responsibility to parse XML. Parse it in
the flowscript and pass the resulting DOM to the view. You can do that
in bizData without using the session at all.
>
> 2. same for wiki syntax
Same as above.
WRT your other points, I agree that the JXTG is somewhat limiited and
clumsy, but don't try to have it do more than what it should, otherwise
you're back to XSP.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: why JXTG sucks? was: FreeMarker integration
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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( 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.
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="${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.
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"
>>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.
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
>>>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.
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 lgawron@mobilebox.pl
Re: why JXTG sucks? was: FreeMarker integration
Posted by Antonio Gallardo <ag...@agssa.net>.
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