Ralph Goers wrote:
Joerg Heinicke wrote:

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 doubt we would use the same XSLTs if our target was a different device. We would probably have a whole different set for mobile phones because the stylesheets would probably have very little in common.. This wouldn't be too big a problem for us. Our main goal is not to have a unique stylesheet for every site.

Basically, we have a bunch of configuration data in an LDAP repository. That data contains the configuration information for one site. A generator then converts that data into an XML document that is aggregated together with our DTO data. The stylesheets then use the data from the model (the DTO) along with the configuration to figure out how to layout the page and what the content should be. This is a simplified version of what happens, but hopefully you get the idea.

On which level does your configuration data (LDAP) describe your page? Let's say that you have a personDTO and you add a birthdate property. Whould this make it necessary to update all configurations that describe pages using the personDTO?


--
Reinhard

Reply via email to