cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Layout-driven vs. content-driven
Date Thu, 02 Mar 2000 11:18:56 GMT
Gerard van Enk wrote:
> 
> > > > The thought is taking shape. It depends on where the final "merging"
> > > > should occour. If the final merging occours on the server
> > side, you use
> > > > XINCLUDE, if on the client side, XLINK...
> > >
> > > I'm not sure if I understand what you're saying.
> > >
> > > Is the following possible with Xlink/Xpointer? I'm not finished reading
> > > everything from the Xlink/Xpointer documentation.......
> > >
> > > 1. There's a layout-template in which the layout is defined.
> > > 2. This template is merged with the content using Xinclude.
> > > 3. A stylesheet is applied to the merged file. This produces a frameset
> > > which is sent to the browser. This frameset contains URIs which can be
> > > translated by Cocoon into Xpointers. These Xpointers are
> > pointers to parts
> > > of the merged file (step 2).
> >
> > Why so? In case of HTML frames, the layout is simply translated into a
> > frameset and the URIs are translated. It will be the browser to call the
> > URIs. No need to mess around with XInclude or XPointers if you don't
> > need to "merge" it.
> 
> But how do I define if it's becoming a merged file or a frameset? 

the sitemap will tell.

> I thought this is done by a serializer? 

It was an example. You can also transform FO into HTML using XSLT or
your own magic filter.

> I'd like to use the same file for the html or the pdf.

Sure, then you need lots of serialization logic. Don't get me wrong, I
do believe in this approach as the winner one in the long term... but
right now there are many simpler solution and using the direct layout ->
HTML frameset transformation is the simplest one by far :)

> 
> >
> > > 4. At stylesheet is applied to the parts of the merged file
> > pointed to by
> > > the Xpointers. These are sent back to the browser.
> > >
> > > Is this possible or am I talking nonsens?
> >
> > Sure it is, but what's the point? You get the same functionality anyway.
> > I'm probably missing something.
> >
> > The XInclude part is done in case you want the layout to be rendered as
> > tables. Then you _need_ to include all the pieces into one, but the
> > browser is unaware of what's going on to generate the page. As it should
> > always be.
> 
> But isn't the choice between frames or tables something that must be done in
> the last stage of the processing?

oh, if you want to have that choice, yes, totally.

> I'm happy with the solution of doing it somewhere in the middle of the
> processing chain.......but I thought this was something for the
> serializing.....It's clear I don't understand it as good as I thought I did
> 8-(

No, you got it right. Simply don't forget that there is no only one way
of doing things. Not many (I'm not a great fan of PERL reasoning), but a
few.

Of course, our goal is to make sure that you are not forced to use the
best one, but you do it by yourself. But this takes both time to develop
the software and time for the standards to stability and get digested by
the community.

FO is great, IMO, but it's a pain to learn from the spec... almost
impossible without visual descriptions of the formatting layout. But as
soon as you have visual tools for that... shees, have you seen the SVG
example with the Adobe SVG Viewer as Netscape plugin? no?

Well go www.adobe.com/svg/ and find out. You MUST go there NOW to
understand what I really mean.

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



Mime
View raw message