Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 32355 invoked by uid 500); 7 Aug 2001 18:08:14 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 32316 invoked from network); 7 Aug 2001 18:08:12 -0000 Date: Tue, 7 Aug 2001 14:01:21 +0200 (CEST) From: giacomo X-X-Sender: To: Subject: Re: Some comments on Cocoon 2.0b2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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 > > --------------------------------------------------------------------- > 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