cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Clarification on converter concept
Date Mon, 16 Jul 2007 12:10:36 GMT
Daniel Fagerstrom pisze:
> Joerg Heinicke skrev:
>> On 13.07.2007 10:31, Grzegorz Kossakowski wrote:
> ...
>> Actually I'm not very keen on any templating approach at all. I don't 
>> like to first provide data to some template context and second 
>> retrieve it from there in the template. IMO it's much better to have a 
>> complete push approach and only encroach if it is necessary (like XSLT 
>> templates). (My diploma thesis was about this btw.)
> I prefer a push approach as well. But this project is not about creating 
> the ideal template framework. It is about keeping back compatibility and 
> at the same time giving users a simpler and cleaner way forward for new 
> development and possible refactoring of old stuff.

Yes, I think Daniel is right about my goal.

> AFAIU, it will be possible to use the object model without any default 
> content, (is that true Grzegorz?). In such a scenario you can have a 
> pure push approach, by only pushing the data that should be rendered 
> into the object model.

Yes, there will be default ObjectModel implementation that will collect environmental data
and expose in unified way but you can easily 
write your own implementation (it will have very light-weight interface) that could expose
any data you like and any form you like.

It's a worth to say that thanks to Spring Configurator capabilities it will be extremely easy
to force any our component to use your own 
ObjectModel implementation.

> I preferred that kind of solution once. But now I find it unnecessary 
> complicated in most cases. The first problem is that it requires some 
> work to convert bean structure to XML data. You will probably need some 
> configuration file that handle part of the conversion. In comparison to 
> just applying an EL to a bean structure it is more complicated. Second, 
> many people find XSLT much more complicated than a simple template 
> language. Third, the development of XSLT processors and tooling, has 
> been a disappointment. Xalan, still doesn't implement XSLT 2.0, and the 
> error messages from both Xalan and Saxon can often be cryptic or non 
> existent.

Same feelings here, unfortunately (I find XSLT really nice as idea).

Grzegorz Kossakowski

View raw message