cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] the quest for the perfect template language
Date Fri, 04 Apr 2003 21:11:55 GMT
Hunsberger, Peter wrote:

>>>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 &gt; 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.



Mime
View raw message