Stefano Mazzocchi <[EMAIL PROTECTED]>
<snip/>
if the sitemap is the ultimate pipeline engine and the flow is the ultimate (and transparently statefull!) controller engine, what is the *ultimate* view, the best template system?
There are a bunch of paradigms on the table but they can be separated in two big groups.
1) generation based 2) transformation based
both can be divided further into
a) compilation based b) interpretation based
Would perhaps "functional" and "procedural" another useful way to slice and dice this?
No, as I explained previously, XSLT crosscuts these concerns.
So, the point is: compilation is useful only if its used to remove operations that are not going to be needed.
I would suggest that optimization and compilation are really two completely different things...???
Rather the opposite, I would suggest that compilation is only another way to optimize code execution. Only done at different stages.
It's the software economy that infected you with the meme that source code and machine code are two different things.
It is entirely possible to write a hardware CPU that executes java code. I mean *CODE*, source code. What difference did it make for me if my Commodore Vic20 ran BASIC code interpreted by a software program running in ROM or a software program running in microcode inside the CPU?
Look at Transmeta CodeMorphing: what is doing interpretation and what is doing compilation? The more virtual layers you have the more the line between compilation and interpretation is blurred.
Here are my thoughts:
1) I've come to the conclusion that we need both generation-based and transformation-based approaches.
Why?
well, the first is useful when you have non-xml data fed into the view, the second is useful when you have xml data fed into the view.
Well, in the first case you can always generate XML from the non-XML and still only use transformation for the "template".
Consider push/pull. Admittedly, a generator is a transformer without the input. Almost by definition. But the reason why a transformer exists is that the input is acquired in push and the orthogonal object model is acquired in pull.
For example, suppose you get a DOM-like data strucure that represents your XML database.
If you want to process it complete, you push it thru a transformer. If you want to access only a few parts of it, you give the root node to a generator and let the generator logic deal with it, pulling only the things that it needs.
Push vs. Pull. Procedural vs. Declarative. XSLT vs. XQuery.
All do the same thing but are a 'rotation' of the solution space around the 'algorithmical optimization axis'.
3) all template languages will need a) variable expansion b) conditionals c) iterations and nothing more!
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.
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. ;-)
5) control should be inverted: the template must be a view, it should be 'pushed' the data in, it should not contain any data-pulling logic other than the one used to pull data from the dataset passed on by the underlying controlling stage.
Perhaps, but, consider for a moment the recent discussion on xmls-dev that
pointed out that Continuations enabled languages enable pull based
processing in a very simple to use way: perhaps your real presentation model
isn't analogous to MVC at all (as you sort of seem to assume?). Perhaps a
pipeline system really needs something completely different for it's
"architecture" (in a loose sense)?
Yes, I think this is the really the case.
What happens if we completely remove any HTTP (stateless/stateful) assumptions and deal only with life cycled data sets that happen to have a presentation rendering riding on top of them (going along for the ride as it where). Combining pull based models on top of streams seems inherently unworkable until you have Continuations, but once you have them then you can think of the stream as being continually persistent and presentation rendering pulling only what is needed at the points the flow engine tells it to...
Bingo!!!! You hit the nail right on the head! This is very *very* close to what it's coming out of my neural fog in my mind... but still I can't grasp the shape of it.
IMHO, the template language which is closer to the optimum is XSLT but only with one change:
FORGET THE XML SYNTAX!
I'm entering wild mode now, so bear with me. Suppose you had:
1) a syntax that is simple and efficient to describe a stylesheet 2) a defined object model accessible thru regular path queries 3) no ability to call extensions
No thanks; why reinvent the wheel? It seems only because of your assumption
4) and that I don't think justifies the end. However (playing devils
advocate for a moment), I will note that SGML allows for more compact
notations than those used by XML...
more compact notations but still markup.
I think that both XSLT and RDF made a huge mistake in using the XML syntax for 'elegance sake'.
Look at CSS. It's clean, it's great, it's *TOTALLY DECLARATIVE* and rightly so.
XSLT has *NOTHING* to do with style. They should finally admit it and drop the ball: come up with a 'xml transformation language', half-declarative, half-procedural, drop the stupid xml syntax and make the world happy.
It's not about reinventing the wheel, Peter. It's about oiling it so that it doesn't squeek anymore!
Hmm, I have transformations where the input object is empty. (Abstractly) I use that to determine that the user is doing a search instead of displaying a result set... But then, I don't think you're using that as a way to control which is chosen, just after the fact to handle either case. However, is that really needed? Is there a real use case for reusing the template in this way that isn't covered by generation feeding transformation?
No, I'm not suggesting to reuse the same *template* for both, but the same *template mechanism*. Chris added a jxpath transformer to the scratchpad and that allows us to reuse the jxpath concepts in both generation and transformation.
And I finally came to the conclusion that there is value in having the ability to use the same logic in the two different realms (push based -> transformation and pull based -> generation)
I'm simply suggesting that using XSLT would make much more sense than jexl or jxpath and even XSP and Velocity for generation, but only if we come up with a more human-oriented syntax.
What do you think?
Interesting, but I don't see that it really buys me anything I don't already have with XSLT except the requirement to implement and maintain Yet Another Language (YAL(tm))...
If it's only syntax sugar, you can transparently come up with a *real* stylesheet. Just like you do with the non-xml syntax of relaxng.
Stefano.
