cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Layout-driven vs. content-driven
Date Tue, 29 Feb 2000 14:31:02 GMT
Pierpaolo Fumagalli wrote:
> Stefano Mazzocchi wrote:
> >
> > Hi guys,
> > here is another episode of the "Stefano's random thoughts" series. The
> > title says it all.
> I like it... I think I should start archieving them...
> > I've been addressed by some that think that Cocoon is heavily
> > content-biased. This implies that Cocoon doesn't work well where the
> > structure of the page is the key and the content is just that,
> > content... what rules is the container.
> I was thinking RIGHT at the same thing... Yesterday at XTECH a guy asked
> me about Cocoon 2.0 and frames, and one of those idle tasks started in
> background in my brain...
> > Such a language does not exist, but there is an equivalent in the HTML
> > world: framesets. When you define frame-driven web sites, you write an
> > entry html page that specify the layout of the page, frame-wise. Then,
> > the browser will connect to the required frames and place the responsed
> > content in the visual containers.
> The HTML spec addresses one specific thing: How to display multiple
> sources into one single "view"...
> > XInclude is a W3C note, it's not even a working draft, but it's a very
> > high quality note and cames from the work of the XLink WG. Please, take
> > a look at:
> >
> >
> While XINCLUDE addresses another problem, how to merge different source
> documents into one.

Not only that, XInclude can be used recursively: I include in one
document a document that is generated by another pipeline.

> The two functionalities are "different" imo. In the first case (frames)
> you deal with multiple URIs represented into the same "view", while in
> the second one, you have one unique URI...

There is no real difference on this. With HTML frames, you map the URI
to a frameset definition. The fact that the content is not already
present is a language choice, but would not make any difference to
include all into one page.

It's a language decision, not a design one.
> It's kinda hard to put it down in words, the thought is yet a little bit
> cloudy, and deals mostly with something I'm thinking about on the
> sitemap and link translations...

I can't picture link translation in this case either... still too foggy
out in these damanged brain cells :)

> > Not all the issues have been resolved with this approach and performance
> > tuning and caching and pre-compilation should be addressed later on, but
> > consider this food for thought.
> It would be nice to have a xinclude processor... and actually it's kinda
> trivial to do it in cocoon 2.0, when you get the right element, you just
> "nest" another parsing operation...

again, you think at Xinclude as inclusion of static files. This is

> > Enjoy, and stay tuned for another epidode of the series "RT: live from
> > Stefano's damaged brain cells" :)
> Waiting for the next one (move it, I don't want to get old waiting)

Don't push me, kid :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message