cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
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 ${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


Mime
View raw message