Pier Fumagalli <[EMAIL PROTECTED]> wrote: > Whilst I am in perfect agreement with most of what you said, > there are a few bits that in my own little heretically > pervert vision still do not comply.
<snip on preface and example/> > > If, instead, I were able to do content aggregation directly > on the view, well, then that would be _MARVELOUS_, because I > won't have to prepare any extended dataset when the editorial > team decides that they want some extra information on the > page, right? Editorial talks to graphic, and development > flies straight out of the picture... > > So, yes, the view should be "pushed" data (in term that it > should not control its generation), but at the same time the > view should be able to "aggregate" different data sources, > because I (who manage the data), don't want to know ANYTHING > about what the graphic and editorial team wants to display to > our visitors... I think you don't want to aggregate "on" the view, but rather as a result of the model: the model should know where the various pieces of data hang out and do the aggregation as needed then make it all available to the view? > > [...] > > IMHO, the template language which is closer to the optimum is XSLT > > The problem I see that I see with XSLT is that XSLT is an > transformation language, not a templating engine (templating, > in my vocabulary, means "fill in the blanks" kind of thing). Good point. However, XSLT can be a darn good template transformation engine.... > > And if you think of pulling more and more data sources into > the same view, the whole thing becomes more and more > complicated... There's the rub: at some point this becomes computationally expensive. However, I don't see how you can have it both ways? Either you do the work or the machine does the work. Given the declining year over year cost of hardware I tend towards the latter, but maybe I'm just lazy... > > But if you asked me about the "perfect template language", it > would be a some sort of "content aggregator with XPath" > generator, where, given the following sitemap: > I could live with that, it's sort of close to what we currently do, but we use pure namespaced XML to specify the differing aggregated components... <snip/> > ... I don't know... Maybe I don't make sense myself, but I'm > troubled as I know that my graphic team won't pick up XSLT > and won't think about the data structures, and without that, > right now, it's quite hard to get all the other advantages of > cocoon... > We've got limited requirements to create new look and feel (or new content for that matter). As a result our graphics team (all two of them) are big into XSLT, it gives them job security.... ;-)
