Re: Some comments on Cocoon 2.0b2

[giacomo <gi...@apache.org>]

On Tue, 24 Jul 2001, Stuart Roebuck wrote:

>
> 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).

Do I understand you correctly? A Generator should be the counterpart of
the Serializer. While the Serializers only responsability is to convert
a SAX event stream to a byte stream, the Generators only responsability
should be to generate a SAX stream from an input sources (be it a
DOM-Fragment created by an Action, a file from the file system, a.s.o).
And the "real" processing will be done by Transformers.

Well, it is worth discussing it's pros and cons, don't you?

Giacomo

>
> > 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
>
>
>
>


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