Diwaker Gupta wrote:
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?
See my overlapping email, I too am a little confused by this (and I was present at the Hackathon).
On Saturday 30 July 2005 7:03 am, Thorsten Scherler wrote:
...
I'm not very good with all the buzz words. Here's my (simplified) understanding (kindly correct if I'm mistaken):
Thorsten was christened the "Master of Confusion" at the Hackathon. It was generally agreed that his ideas are brilliant, those of us lagging a light year or so behind just have to work hard to understand them. Thanks for your simplified view I'm sure it helps us all ;-)
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).
Yes. I think it is vital that we post the summary of the Hackathon discussions before getting deep into this discussion as this was one of the main things we discussed. There is an audio file in SVN (tanks David) but nevertheless we should still post a summary of the discussions for the benefit of those who were not present, otherwise not everyone will be able to participate at the same level of understanding.
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?
This was discussed at the hackathon, and I just sent a mail to help us agree terminology.
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
+1
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)
This was not discussed at ApacheCon. Perhaps when the flurry of discussion has died down a little you can raise this point again. It seems there is already a level of consensus that plugins should be able to provide contracts. It's a question of how we implement it.
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.
This was touched on at ApacheCon. in fact it was pointed out that the current way of defining a view can't be reused in other formats as it has the concept of head and body hard coded whilst other formats don't have them (text for example) or have a more complex representation of them (FO for example).
I agree that this is an extremely important issue that we need to address sooner rather than later. In my view this fits into the configuration point above - would you agree?
Ross
