cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Washeim <esa...@canuck.com>
Subject Re: Cocoon2 Design WAS: [cocoon 2] removing bottenecks
Date Mon, 29 May 2000 07:55:58 GMT
on 29/5/00 12:27 am, Stefano Mazzocchi at stefano@apache.org wrote:

> Jeremy Quinn wrote:
>> 
>>> Same here. It's always a pleasure to test our ideas against different
>>> views.
>> 
>> Stefano,
>> 
>> I don't know if this is the right time, but remember that "Layout"
>> idea that was knocking around a while ago?
>> 
>> It was to do with laying our regions of the "page", defining
>> resources to be transformed into each one. People had it confused
>> with Frames ....
>> 
>> As you are growing the SiteMap in such interesting directions, I was
>> wonder if this fits in.
> 
> For what I see, this is completely orthogonal from a sitemap
> perspective.
> 
> I mean, even if not possible, the sitemap will allow components and URI
> to be assembled to create what you need.
> 
> If not, well, I agree we have a problem since layout-driven publishing
> is probably the most common way to do things on paper and should be like
> that on digital media too.
> 
> But I don't see where the sitemap could limit that operation, XInclude
> filters will allow the generation of a page by constructing fragments of
> other URIs, each of them, using a different pipeline.

I'm not sure if this is helpful to the discussion but, two points:

1. The Layout notion attendant to a turbine application has been completely
useless to us since it entails that wrong contract. Namely, that a
programmer have a direct role in the layout which is rarely the case.

2. I'm currently working on a site which I'm using what you might call
'layout templates' in a cocoon context. As Stefano intimates, I'm simply
including other documents into several variant templates.

In this case the templates (xsp pages) serve as nothing more than the layout
(and do a bit of session state maintenance stuff) whereas the content is
from entirely different origins. Thus far, we have both static documents
being included and SQL taglib employing pages.

In the main, it does accomplish separation of the content from the layout
and leave it in the hands of someone who doesn't need to concern themselves
with the application logic. Even the xsp in this case isn't an issue, since
it's 'spare'. 
-- 
Mark (Poetaster) Washeim

'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.

Quem colorem habet sapientia?'

Evan S. Connell

 



Mime
View raw message