cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerard van Enk" <gerard.van....@eo.nl>
Subject RE: [RT] Layout-driven vs. content-driven
Date Tue, 29 Feb 2000 12:03:49 GMT
> 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 believe the above is not correct if you look at Cocoon under the right
> perspective.
>
> 1) layout is another form of content
>
> 2) cocoon doesn't assume anything about what is "generated" to start the
> pipeline process. It could contain the data to present, or may contain
> data that is used later in the stage to trigger execution.
>
> Now, the real question is: is Cocoon ready for a layout-driven approach?
>
> The final answer is: its architecture is, its implementation is not.
>
> I'll outline what I believe is a possible solution for the problem...
> but first we must outline the problem.
>
> Consider something like this
>
>    +----+-------------------+
>    |logo|      topbar       |
>    +----+-------------------+
>    | s  |                   |
>    | i  |                   |
>    | t  |                   |
>    | e  |                   |
>    | b  |                   |
>    | a  |                   |
>    | r  |      content      |
>    +----+                   |
>    | n  |                   |
>    | e  |                   |
>    | w  |                   |
>    | s  |                   |
>    +----+-------------------+
>
> which represents a site layout (please, don't abuse me if you don't like
> the visual appeal, my point is structural, not visual)
>
> Let us suppose we have a layout-definition language. This language
> should:
>
>  a) identify content containers
>  b) define their structure and relationship between them
>  c) contain the instructions on how to fill-up the container the with
> proper content
>  d) be reusable across the site
>  e) contain metadata about the containers (optional)
>
> however, it should not:
>
>  a) contain any stylying/visual information
>  b) contain any content processing information
>
> 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.
>
> Now, suppose you have a way to define the structure of you page without
> explicitly including visual information... you could have a way to
> "construct" your page, structure-wise, with different content (a-la
> portal) and care about their visual representation later.
>
> Also, this page should be able to be processed on the server side and
> the architecture should do the inclusion for us, instead of the browser.
>
> I have no idea of how this language should look like (yet), but one
> thing is for sure, Cocoon lacks a very important piece of the puzzle:
> XInclude!!
>
> 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:
>
>   http://www.w3.org/TR/xinclude
>
> XInclude specifies a way to include a document or parts of a document
> (using XPointer and XPath) in the original XML document. As they say,
> "merging a number of XML Infosets into a single composite Infoset".
>
> Now, let's look again at a possible marked-up representation of the
> layout
>
>  <area name="page" xmlns:x="http://www.w3.org/1999/XML/xinclude">
>   <area name="top">
>    <area name="logo">
>     <x:xinclude x:href="/images/logo.svg" x:parse="xml"/>
>    </area>
>    <area name="bar">
>     <x:xinclude x:href="/images/topbar.svg" x:parse="xml"/>
>    </area>
>   </area>
>   <area name="side">
>    <area name="index">
>     <x:xinclude x:href="/index.fo" x:parse="xml"/>
>    </area>
>    <area name="news">
>     <area name="mynews">
>      <x:xinclude x:href="/news/mynews.fo" x:parse="xml"/>
>     </area>
>    </area>
>   </area>
>   <area name="content">
>    <x:xinclude x:href="/docs/content" x:parse="xml" x:steps="2"/>
>   </area>
>  </area>
>

What is the best way to include dynamic information into the
layout-template? The above example is static (or I'm I missing something?).
I have to change the x:href for every page.....I'd like to have one
layout-template where information will be dynamically included. Or do I have
to use the sitemap for this?

What if the content comes out of a database? Do I need to use the x:href to
include an xml-file with XSP-tags that can access a databse? Or is there a
better way?

What if I wanna use frames for the layout? I can't use the above example
because all the information is included in a single file.............

> Enjoy, and stay tuned for another epidode of the series "RT: live from
> Stefano's damaged brain cells" :)

I can't wait........;-)

Gerard


Mime
View raw message