Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>
> Hunsberger, Peter wrote:
> > Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> >
> > <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.
Huh? XSLT should be purely functional. I don't see this? (No real need to
explain, it's not really an issue).
> >>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.
This has nothing to do with source code vs. machine code. Compilation is
the conversion of code from one format to another. Optimization is the
process of improving the efficiency of code. Two different things (but
again, I don't see that it matters for the issue at hand)...
> 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.
That still doesn't make compilation _necessarily_ a form of optimization.
In fact, it shows the opposite: code compiled to run efficiently on X86
architecture may be no where near the code that could run the optimally on a
Transmeta processor...
<snip/>
> >>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.
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 / <------------------------/
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. 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.
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).
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).
> >>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"
>
> >>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.
>
Nor can I quite, now you know why I have such a hard time explaining what I
want to everyone...
Maybe here's another way to look at it: for any given single user caching
isn't needed because their "stream" is always persistent, it just keeps
getting transformed to different views (sometimes there's lots of stuff in
it, sometimes very little). Caching doesn't go away across the system since
what was created for one user may be useful to another user starting from
the same point. But you're no longer caching to, for example, stop from
having to get the model before and after presentation. The stream is
persistent, when the continuation returns you've still got it to play with
and now you can add new results to it. Push and pull are perhaps bad
semantics; at best you push the presentation into existence and it pulls
from the stream what it needs.
<snip on XML rant>
>
> 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!
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!), but let's not complicate Cocoon with it until you've got a standard
to shoot at....
<snip>
