cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Sun, 07 Nov 2004 17:03:10 GMT
Leszek Gawron dijo:
> Joerg Heinicke wrote:
>> On 05.11.2004 11:19, Leszek Gawron wrote:
>>> Still this is very inconvenient if the model is built for you i.e.
>>> object graph built by hibernate. I would have to make controller
>>> dependant on view view wants to show. Right now I just pass one entity
>>> to view and do not care if view asks for entity fields, entity parent
>>> fields, child fields, anything. If I have hibernate properly set up
>>> the data will be retrieved only when needed.
>> But the view is not reusable.
> Now I get it why some cocooners have such a different opinion. I think
> there are two worlds that cocoon covers:
> - xml publishing, dynamic sites but with not that much business logic.
> Here the most work is put into data aggregation and rendering. I think
> your opinion represents this world.
> - web applications, totally dynamic, a lot of business logic. Most work
> is put into model and business logic. The controller is also
> significantly more complex. View is the least sophisticated here. This
> is my world :)

Yep. This is true. To me this exactly one of the most interesting parts of
Cocoon. We like to see solutions that fit in both worlds.

Often we find it ;-)

This is one of the things why Cocoon rocks!

> I am developing web applications. That is why the main concern for me is
> the MODEL reusability. I do not care about the view reusability as
> almost everything is modelled in html (For styling I use single
> site2html.xsl which applies common styles, toolbar and menu). For apps I
> seldom use aggregation and 99% views are JX generated.

I think is posible to care a lot about the MODEL reusability and at the
same time use rendering pipelines for various formats.

In my case JXTG represent cca. 40-50 % of the views.

> I've done a few publishing projects. I agreee with you but only on the
> field of publishing projects where the rendering pipelines are huge and
> usually you produce data in various formats (HTML, PDF, printable HTML).
>>> I have project that model have 5-6 depts in parent-child relationship
>>> like:
>>> contractor -> surveydefinition -> questioncategory ->
>>> questiondefinition -> alertcategory -> alertdefinition.
>>> While displaying list of entities on any level I can choose to add
>>> additional column with link to parent on any level and the only thing
>>> I have to change is the template. Model remains the same.

>> If the model changes the view has also to change.
> What I try to emphasize: If the view changes the the model doesn't
> necessarily have to change.

I think this is correct and currently is working in this way or not?
The SoC idea means both (model and view) are independents each other.

> For web applications:
> - the model is the first to be agreed upon/designed/implemented
> - the model is the core of the application and most weight is shifted in
> that direction
> - the model is strongly typed, has a lot of constraints. Almost whole
> model consists of POJOS.
> - the model does not change much. If it does it's much bigger problem
> than just updating the views because it involves a lot of business logic
> to be changed.
> That is why I need my model (especially built by hibernate) to be clear
> and reusable. Not the view.
> Also I need the rendering logic to be applied in the view and not
> earlier. I need to be able to choose a convertor during view generation:
> - I might want to show property value in plain text in one place (for
> editing) and in the same view pretty printed below.
> - I do not want all Integers < 0 to be rendered red. This is based on
> the context. It is also inconvenient to put that info into the model as
> there may be a lot of orthogonal views of the same data. The model would
> have to support everyone.

Yep. This is the idea. But we need to take care that there can be other
rendering views too.

>> You all seem to have
>> only just one view in mind. What about having different views for
>> different browsers or devices? While it might be easy for browsers by
>> using XSLT and change here and there a bit, it's nearly impossible for
>> different devices. Who takes control whether to show 5 widgets or 50?
>> Using templates it's only possible by using different templates. And so
>> if the model changes the different templates have also to change. And
>> the templates are still not reusable!
> Probably we need either 2 templating languages or a single one covering
> both approaches.

The later better. Or what about 1 tranformer for the views?

>> Shall the view decide it? Even with renderers/converters this makes it
>> being not reusable. As Terrence Parr wrote: The view should be reusable
>> with a completely different model. The configuration must happen
>> externally, i.e. neither in model nor in view.
> This clearly makes the difference for web applications: The model should
> be reusable with a completely different view :)

Both statements share in common what I told above:

I think is posible to care a lot about the MODEL reusability and at the
same time use rendering pipelines for various formats.

Best Regards,

Antonio Gallardo

View raw message