Are you sure they don't need to be Turing complete? I suspect so...
See my previous reply: what should be in charge of 'adapting' the data for the view? the view itself or the underlying controlling stage?
Instead of
controller -(model)-> view
I would separate 'controller' into many different parts
controller -(model)-> adaptor -(view data)-> view
where 'adaptor' needs to be turing complete and it's written by programmers while 'view' is non-turing complete and it's written by designers.
But I'm really not sure of how this would operate in real life.
Ok, I'm starting to see what you're getting at and I'll bite: we're doing something like this, but it's nothing like what you've described to date. Our model is more like:
model
/ \ BL controller \
\ data - adaptor -> presentation <- flow controller
/ / view / <------------------------/
know what? you really suck at ASCII drawing ;-)
Seriously, I don't see the difference between a presentation and a view. Besides, the flow of the above is really not understandable.
If you care to elaborate more, I'm all ears.
Though that's a quick approximation, the two main points are that
controlling the model and controlling the presentation are two separate
issues and the "adaptation" of the data to fit the view should be
independent of the presentation.
Yep, the reason for this, for example, is locale adaptation. something like the I18Ntransformer perfectly fits in the adaptation stage.
We've been able to keep conditionals and iterations out of the view templates. Instead there are triggers in the templates that cause differing evaluations of the template dependant on the data and iteration is done by data inspection: if the data that matches a portion of the template occurs multiple times then iteration over the data is required. Our views are pretty much dead simple XML. The "adaptor" is some heavyweight XSLT.
I more and more concerned about heaviweight XSLT stuff. As much as I would be if my core adapting technology was something cryptical like Perl.
This may not meet the needs of those people who are constantly creating new look and feel: our presentation is also XSLT, though they are simple since the adaptor has done all the heavy lifting of creating a common abstract object model used by all presentation transformations. None-the-less, if you can't rely on CSS you're still going to have to do a lot of HTML encoding in the presentation layer. In-other-words; our views are a filter driving a transformation on what the data looks like and not a complete style specification (though more and more style semantics keep creeping in).
Yes, I'm worried about the 'simple little addition' that turns into a huge and unrefactorable mess over the years. But this is forecasting in wild mode so take with a grain of salt.
Note: I keep asking for work flow capabilities above and beyond the Cocoon flow capabilities. The reason falls out of the above diagram: for may things I want a _simple_ way of getting back and forth from the flow controller to the BL controller (right now it's Cocoon actions and business logic encoded in the sitemap).
Why doesn't flowscript fit your needs?
4) verbosity of the syntax must be balanced: too few verbosity is
efficient but grows into obscurity (ie Perl), too much verbosity is harmful because signal/noise ratio is reduced.
Bah: with modern high resolution monitors and syntax highlighting/context sensitive/auto completing editors this is a specious argument at best...
Whatever monitor or xml editor you have, writing
<xsl:if test="3 > 4">
will still keep on sucking ass. ;-)
I'm not a big fan of the XML syntax, but it doesn't drive me crazy. How
about we go back to GML?
:choose :when.test="3 >4".select="gunk" :otherwise.select="foo"
c'mon, Peter. I'm not meaning to insult everyone, but to solve an issue I'm having about the fact that I want a template engine that is SAX based and works with some velocity-like syntax and XSLT fits the need perfectly if it wasn't for the stynax.
I want something I can give to an HTML designer without seeing him drop his/her jaw. HTML+CSS+javascript is ok. XHTML is at reach and will be ok soon. As soon as they realize that browser behaves better on XHTML than they do on HTML.
But XSLT (with its current syntax) is not and will never be!
It's just style, after all, right? but ask your graphic designers why they cry for a mac or why they spend days finding the perfect color shades.
Style, for them, is everything.
SoC means 'the right tool, for the right person'.
XSLT is the right tool for what kind of person? a programmer.
But it's also the tool that we suggest for creating the presentation. And who's concer is that? the designer's!
Result: either you find a special half-programmer/half-designer XSLT-ist (which is as rare as gold, even nowadays), or you have to force your programmers act as designers (doing mostly a poor job) or your designers to act as programmers.
And you can kiss goodbye to clean SoC between style and logic.
What I'm advocating is:
- XSLT as a transformer for programmers - XSLT as a generator (templates) for designers
This keeps concerns well separate, and shares the same underlying engine.
But in order for this to happen, the XSLT syntax for designers must be simplified, or they will never use it.
And yes, probably because deep inside I envy designers for their visual art talents, I do resonate with them sometimes :-)
It's not about reinventing the wheel, Peter. It's about oiling it so that it doesn't squeek anymore!
I'd be all for that, but I don't think this is something that Cocoon has to do. Maybe you personally need to start another W3C working group to do this (hah!)
nop, that's not possible. I'm not a W3C member so I can't propose any notes, unless I'm an invited expert.
And I think I managed to piss off too many people on the XSL WG, so don't count on me getting invited anywhere near them :-)
but let's not complicate Cocoon with it until you've got a standard to shoot at....
Nah, that's for whimps ;-)
-- Stefano.
