cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: [RT] Content aggregation
Date Wed, 04 Oct 2000 10:40:22 GMT
Stefano Mazzocchi wrote:

>                         -------------- o -------------
> Ok, now we have aggregated content.... what do we do with it?
> We have to style it.

This is the hardest part, I believe.
A single aggregated resource, possibly dynamically generated, has the need
for the ability to split into a bunch of HTML pages, such as a Framed

> Smart, isn't it?
> There are two different style concerns: area placing (layout) and
> content adaptation (style). Normally, the two things are done by
> different people: the layout writer is not usually an artist, but it's
> more a user interface designer that looks at different locations for
> information and understand where the things should work best.
> >From the most simple web site to the most complex portal, layout is a
> fundamental part of every 2D interface: newspapers invented the idea of
> 2D layout and visual design patterns... while the "look" of the page is
> defined by the style, the "feel" of the page is defined by its layout.
> Cocoon must therefore allow these concerns to be separated.
> How? well, let's try to come with a reasonable solution... we now we
> have a highly orthogonal document which contains n+2 namespaces where n
> is the number of aggregated resources (each resource to be aggregated
> *MUST* output a namespace, this will be absolutely required and Cocoon
> might signal an error in case no namespace is present to avoid
> collisions)
> (+2 'cause of the xlink and structure namespace)
> ok, let's see...
>  <generate type="aggretator">
>   ...
>  </generate>
>  <transform src="/www/graphics/fancy/structure2html.xsl"/>
>  <transform src="/www/graphics/fancy/navbar2html.xsl"/>
>  <transform src="/www/graphics/fancy/doc2html.xsl"/>
>  <serialize type="html"/>
> where
>  - structure2html generates the layout frame and copies all the other
> namespaces
>  - navbar2html stylizes the navbar but leaves all the rest untouched.
>  - doc2html does the same thing for the doc

My gut feeling is that this is possibly much harder than it first seems,
especially if you drop in the cache aspect of it on top. But let's drop
that for a second.
It is not enough to have a Aggregator combined with general-purpose
Transformers. The Aggregator does not know if the aggregated result will be
broken into many pieces or not, only the Transformation + Serialization
package has that knowledge. I have the feeling that this concept needs to
be introduced to the sitemap, not only for Aggregation, but also for other
usage. It is a bit related to branching the SAX and feeding more than one

 <generate type="aggretator">
        <transform resultID="titlebar"
        <serialize type="html"/>
        <transform resultID="sidebar"
        <serialize type="html"/>
        <transform resultID="content"
        <serialize type="html"/>
        <transform resultID="stockchart"
        <serialize type="svg2png"/>
    <dyn-resource resultID="structure" >
        <transform src="/www/graphics/fancy/structure2html.xsl" />
        <serialize type="html"/>

And that the branch handler will be a virtual response handler, saving the
serialized content to temporary storage and feed each of the dyn-resources
with the resultIDs of the other dyn-resources as parameters to each of
them. (Cyclic dependencies makes it more interesting :o) )

("resultID" should probably be called "uri". Just lazy to change it.)


View raw message