cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <stuart.roeb...@adolos.co.uk>
Subject Re: Some comments on Cocoon 2.0b2
Date Tue, 24 Jul 2001 11:21:11 GMT

On Tuesday, July 24, 2001, at 11:25  am, Stefano Mazzocchi wrote:

> content aggregation
> -------------------
>
> Content aggregation at sitemap level is, IMHO, limiting and imposes some
> degree of overlap between concerns.
>
> An example clarifies this in detail: suppose you want to create some
> JetSpeed-like application using Cocoon2. Aggregation on the same
> resource (say '/') should depend on user identity and its preferences
> (think my.netscape.com) which might be stored someplace in a database,
> LDAP, file, memory, session, cookie, you name it.
>
> This is not possible if the aggregation controls are hardwired into the
> sitemap.
>
> It has been recently noted how there is no component that "aggregates".
>
> Sure, you could say: ok, let's make a pluggable aggregating component to
> make this user-preferred portal possible.
>
> Yes, that's a solution, but I believe the design mistake here is that
> "aggregation" is seen as "generation" while I see it as
> "transformation".
...

The "what is a generator" question you raise is one I was thinking about 
the other day.

Wouldn't it be a lot tidier if we decided that anything that takes an XML 
input and transforms it in some way to create an XML output should be a 
transformer and that Generators should simply be means of obtaining raw 
input in a suitable form for processing.

This means that the ServerPagesGenerator would be a Transformer taking XSP 
as input (from a Generator).

> Cocoon:/ protocol
> -----------------
>
> While I consider the concept of being able to refert to sitemap
> generated resources directly with a specific protocol very good, I
> question the necessity for the ability to access the root of the
> sitemap.
>
> I'm still not sure myself about this, but I believe that it might lead
> to concern overlap between the different people responsible for the
> different sitemaps.
>
> One of the original goals of the sitemap semantics were that they must
> be fully "relocatable": this means that you can mount your sitemap on
> "/news" one day and on "/new-news" the next without having to tell the
> people responsible for the "news" sitemap.
>
> It's true that the use of absolute paths doesn't break sitemap
> relocability, but we must avoid something like
>
>  cocoon:/../logo
>
> since *this* breaks relocability since it assumes something on the mount
> point of the sitemap and this is *bad*!
>
> Also we must ask ourselves if the ability of having absolute access to
> nternal resources might result in contract failure between the concern
> islands responsible for the current sitemap and the root sitemap.
>
> I honestly don't know, let's see if my comments trigger something.
>
> now some RT I'm having in the back of my mind

I'm comfortable that this access to the root sitemap is valuable.  The 
root provides a mechanism for handling 'global' or 'common' elements of a 
site independent of the location of subsitemaps.


Stuart.

-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                               Java, XML, MacOS X, XP, etc.
ADOLOS                                           <http://www.adolos.com/>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message