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 16:24:04 GMT
> Gerard van Enk wrote:
> >
> > > 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?
>
> Ouch, you guys are quick... that was the subject for my next RT... but I
> didn't have the time to think about it.
>
> > The above example is static (or I'm I missing something?).
>
> Yes is it. On purpose.
>
> > 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?
>
> Good question. I can't possibly know all the answers right away :)

ok, I can think of two solutions:

1. Use XSP-tags in the layout-template. And process these tags before the
xinclude processor.
2. Use parameters for the xinclude processor in the sitemap which have the
same name as the area tags in the layout template, for example:

<process match="news/*.xml>
 <generator type="file" src="/layout/standard"/>
  <filter type="xinclude">
   <parameter name="content" value="news/content/*.xml"/>
   <parameter name="topbar" value="layout/menubar.xml"/>
  </filter>
  <filter type="xslt">
   <parameter name="stylesheet" value="layout2fo.xsl"
  </filter>
 <serializer type="fo2html"/>
</process>

But I don't know how dynamic this solution will be.

Other ideas?

>
> > 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?
>
> I do have an anwwer for this: you include a URI. So the sitemap will
> drive the URI generation the regular way. The layout should not contain
> sitemap information.
>

ok, I thought of something like this!

> > 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.............
>
> Wrong. You are still thinking HTML-ish :)
>

I know, I know.....

> suppose you have a single FO + SVG file that includes everything you
> have on that page.
>
> Then you serialize it with
>
>  1) fo2pdf -> you end up with a single PDF with layout content and
> graphics.
>
>  2) fo2html -> you end up with an html frameset that is sent to the
> browser with the frames saved in separate static files + images, all
> properly linked.
>
> I know it's not easy to think it this way, but try to consider FO our
> typesetting description language and HTML as a surrogate for old
> visualizers.
>
> I'm not saying it's easy to come up with something that transforms FO
> into HTML with this power, not at all, but this is the only clear way to
> separate publishing from the limitation of the typesettings language
> used.
>

I think this is a great solution, but when will fop be ready for these kind
of things?????


> Am I making sense at all?

Absolutely!

Gerard


Mime
View raw message