cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: why JXTG sucks? was: FreeMarker integration
Date Tue, 10 Aug 2004 10:41:43 GMT
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 ${}. 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.


View raw message