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
