Forgive me for being obtuse, but I completely missed the "change in procesing paradigm" part :-) I mean, were you talking about a conceptual paradigm shift, or an implementation detail? Conceptually, IIUC, we still follow a dispatcher-view patter, no? I mean Forrest has been about separating content from presentation since the beginning right? If its an implementation detail, then I might just be ignorant, in which case I'll dig in a little more to try and understand what you were saying. More comments inline.
On Saturday 30 July 2005 7:03 am, Thorsten Scherler wrote: > forrest:views will change the way we are processing a request. I > designed it after the Dispatcher View J2EE design pattern [1]. > "Dispatcher View While the analogy to the JEEE DispatcherView design pattern is certainly useful, I think it still leaves the primary questions about views unanswered. [snip business logic stuff] I'm not very good with all the buzz words. Here's my (simplified) understanding (kindly correct if I'm mistaken): Separating content from presentation has always been a central focus in Forrest's design. Views/Templates are just another step in that direction. Contracts give the content, CSS does the presentation (atleast in the XHTML case). > The basic idea is that forrest:views will be a dispatcher config for > 1) including data to the presentation model > 2) generating dynamic presentation I'm confused with the terminology here. Is dynamic used here in the sense of "dynamically generated content", or is it used in the sense of "dynamically changing appearance". It'll be great if you can elaborate a bit more on this in non-J2EE terminology :-) As for data, I think the current contracts are a very good starting point. We have 30+ contracts I believe, and adding new ones is easier. IMHO, the more pertinent issues on views/templates are: o naming and terminology: what is a view? what is a template? given the same content (generated by some "template"), are there different "views" for each output type? o configuration: atleast in my mind there's a lot of confusion as to what configuration should go into skinconf, what should go into plugins, and what should go into views and specific contracts o functionality: should plugins provide relevant contracts? should contracts depend on plugins? IMHO each plugin will need *some* contract, but there can be contracts which don't need any plugins (like one that generates copyright statement or timestamp) o unification: most of the work on views so far has focused on XHTML. again, i'm having a hard time envisioning a unified framework that integrates all input/output formats. Diwaker > [1] http://java.sun.com/j2ee/patterns/DispatcherView.html > [2] http://corej2eepatterns.com/Patterns2ndEd/DispatcherView.htm -- Web/Blog/Gallery: http://floatingsun.net
pgpiW3PhDkWK6.pgp
Description: PGP signature
