cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Tue, 09 Nov 2004 15:07:39 GMT
Joerg Heinicke wrote:
> On 08.11.2004 21:24, Ralph Goers wrote:
> 
>>> Sample: You have an object, that can be viewed and edited. This object
>>> will be extended by adding a further required field when editing it and
>>> would be of interest when viewing it. How much effort do you need to
>>> update all the views that reference it? To what degree can you reuse
>>> your views?
>>> For such a change CForms is really bad. I had to update definitions,
>>> bindings, template so often!
>>
>>
>> I see where we are not connecting.  In my case the issue is not that a 
>> lot
>> of views need to be modified when an object changes. It is that a single
>> use case can have many views.  In this case, we have a single xslt (or a
>> few) that uses parameters to determine what to display and how to do it.
> 
> 
> So your view is more data-driven? We had this in our first Cocoon 
> project Lofex. We had an XML representing the data from the model and 
> XSLT to transform it into HTML (but no configuration how to or what to 
> display, just one XSLT per page). May I ask for more details on your 
> approach. One possible problem I see for a 
> all-and-everything-presentation layer is the decision "how much to put 
> into one page", e.g. for mobile phones. Do you just not need this or how 
> do you have it solved?
> 
> I'm interested in it because I write my diploma thesis exactly about 
> this topic at the moment. I come to the conclusion that MVC more or less 
> can not work - and especially templates! I switched back to a similar 
> solution to the mentioned Lofex one (i.e. application-driven) but with a 
> more sophisticated model than just the data of the application as it was 
> for Lofex. It's build on the pattern "Presentation Abstraction Control" 
> I read first about in German Javamagazin 09/2004.

I (tried to) read this article. AFAIU interesting stuff but a little too 
academic IMHO.
Then I followed the reference to 
http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox_p.html which is 
easier to understand.

The main adavantage of this visual-proxy pattern (which is based upon the 
presentation abstraction control pattern) is, that the complete information that 
belongs to a certain object is encapsulated by it. If you need another property 
on your object, you simply change one object and every other object using it 
doesn't have to be changed.

As you pointed out, cForms requires you to change on many places in the case you 
want to add another property to your object. Is this the price to pay, if you 
want to seperate presentation from data definition to get the possibility to 
support more then one view?

Can you describe the result of your research in your thesis?


-- 
Reinhard

Mime
View raw message