You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2001/07/24 12:25:16 UTC
Some comments on Cocoon 2.0b2
I think you guys are doing a great job. From looking at the CVS commits
and the mail logs this project has never been so healthy and I think I
can finally say that Cocoon is a project that is going to last,
community wise.
This, people, is not so obvious as you would expect: I'm talking about
years in the future, not a few months. After watching many OSS projects
and bootstrapping a few, I believe that Cocoon has the right balance to
keep going for a long time, despite the changes in the development team.
This said, feeling very proud of having started all this and feeling
honored of seeing so many people working actively on such a great
project, I have some small comments to make on the design decisions that
were made in my absence.
Of course, not being there when the design decisions were made, I'm
absolutely happy with the state of the project, I'm just writing you my
comments that you might find helpful.
If not, well, at least I made myself heard. :)
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".
Suppose you have something like this:
generator -> layout page
transformer -> aggregator
now you can have a generator produce the outline of the page and the
transformer (sort of server-side XInclude for XML Inforsets) produce the
aggregated content. The layout might use a specific namespace that is
used to react further namespace behavior on the transformer. For example
<lay:layout xmlns:lay="../cocoon/layout"
xmlns:agg="../cocoon/aggregate">
<agg:include agg:src="hello.xml" agg:ns="http://www.blah.com"/>
</lay:layout>
where "hello.xml" is
<page>
<p>HelloWorld!<p>
</page>
which leads
<lay:layout xmlns:lay="../cocoon/layout"
xmlns:agg="../cocoon/aggregate">
<page xmlns="http://www.blah.com">
<p>HelloWorld!<p>
</page>
</lay:layout>
or something like that.
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
namespace-reacting trasnformations
----------------------------------
There are a bunch of discussions on stylebook/anakia/cocoon these days
going on and I'm happy that Donald set up the Cocoon-By-Cocoon site
since it gives us (finally) a serious place to show off our power.
The usual "my DTD is better than yours" flames will start firing as soon
as we decide what DTD to use.
I heard comments such as "I don't like <link> because I'm used to type
<a> and I end up with <link src="..."></a>". There is no way we can
settle this even if we make the tools available to automatize this.
At the same time, it's pretty piece of cake to do transformations
between tagsets if the semantic meaning is equivalent: if the guy likes
<a>, that's totally fine for me, as long as it's semantically
consistent.
For "semantically consistent" I mean that <a> is always used instead of
<link> and that there is the chance of knowing what that <a> means for
that particular guy.
Now, suppose you want to generate documentation but you "don't" know in
advance the schema used for it. All you know is that your pipeline
expects "docbook" from some point on and you do have some "adaptation
stylesheets" that transform these simplified but semantically equivalent
DTDs into docbook.
So, visually, you have:
generator -[docbook]-> transformer -[fo]-> serializer -[pdf]-> client
but if you don't know in advance the markup used you need to adapt
generator -[???]-> adaptor -[docbook]-> ...
There are two ways to identify the semantic context of the document:
1) DTD/Schema
2) namespace
In the firts case, the behavior is straightforward: depending on the
DTD/Schema, apply a different transformation sheet.
In the second case, if the namespace used is one and only one, the same
behavior applies. Otherwise, the writing of the stylesheets is more
complex since it must copy over all the other tags that don't belong to
the namespace that want to adapt.
Bah, anyway, food for thought.
Ciao.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Some comments on Cocoon 2.0b2
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
> I think you guys are doing a great job. From looking at the CVS commits
> and the mail logs this project has never been so healthy and I think I
> can finally say that Cocoon is a project that is going to last,
> community wise.
Good to hear from you.
> content aggregation
> -------------------
>
> Content aggregation at sitemap level is, IMHO, limiting and imposes some
> degree of overlap between concerns.
I tend to agree. I sent a private email to Giacomo for some ideas on
the next version of Cocoon (he's on vacation so he won't see it until
next week). I am wanting to facilitate a better concern map (which
from using Cocoon for a while I have a better idea of how it should
be).
> 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.
Preach it.
> 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".
>
> Suppose you have something like this:
>
> generator -> layout page
> transformer -> aggregator
>
> now you can have a generator produce the outline of the page and the
> transformer (sort of server-side XInclude for XML Inforsets) produce the
> aggregated content. The layout might use a specific namespace that is
> used to react further namespace behavior on the transformer. For example
>
> <lay:layout xmlns:lay="../cocoon/layout"
> xmlns:agg="../cocoon/aggregate">
> <agg:include agg:src="hello.xml" agg:ns="http://www.blah.com"/>
> </lay:layout>
I see. We have both the XInclude processor and the CInclude processor.
If the XInclude processor can handle the "cocoon:" protocol, we will only
need the standards based version.
> 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.
This approach is necessary many times in real development. You can't
create a site that never has any absolute references if you have all
your images in one directory. Just the same, you can't ensure the
entire site has the same "pipeline" if you can never refer to resources
at the root.
In your paper, you yourself addressed the problem of URLs that change.
This is no exception to that rule.
> 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.
This isn't necessarily a problem though.
> namespace-reacting trasnformations
> ----------------------------------
>
> There are a bunch of discussions on stylebook/anakia/cocoon these days
> going on and I'm happy that Donald set up the Cocoon-By-Cocoon site
> since it gives us (finally) a serious place to show off our power.
Cocoon is also used to build the Avalon documenation written in DocBook.
There is even a Stylebook 2 DocBook conversion stylesheet in Avalon.
Talk about power....
> Now, suppose you want to generate documentation but you "don't" know in
> advance the schema used for it. All you know is that your pipeline
> expects "docbook" from some point on and you do have some "adaptation
> stylesheets" that transform these simplified but semantically equivalent
> DTDs into docbook.
>
> So, visually, you have:
>
> generator -[docbook]-> transformer -[fo]-> serializer -[pdf]-> client
>
> but if you don't know in advance the markup used you need to adapt
>
> generator -[???]-> adaptor -[docbook]-> ...
>
> There are two ways to identify the semantic context of the document:
>
> 1) DTD/Schema
> 2) namespace
>
> In the firts case, the behavior is straightforward: depending on the
> DTD/Schema, apply a different transformation sheet.
>
> In the second case, if the namespace used is one and only one, the same
> behavior applies. Otherwise, the writing of the stylesheets is more
> complex since it must copy over all the other tags that don't belong to
> the namespace that want to adapt.
In the example you outlined, I would tend to say, "Make a decision already!"
Writing documentation or creating a site with semantic markup requires that
the team use a standard for the site. If you don't, you are asking for trouble
later on when you need to maintain the site. Period.
Now, when it comes to transformers that add functionality (such as the
XIncludeTransformer, et. al.), this becomes truly important. In Cocoon 2.1
there is an IntrospectionTransformer that will apply a transformer based on
namespace.
> Ciao.
Ciao.
Re: AW: Some comments on Cocoon 2.0b2
Posted by Sergio Carvalho <se...@acm.org>.
On Tue, 24 Jul 2001 14:40:20 +0200 (CEST), Marcus Crafter <cr...@fztig938.bank.dresdner.net> wrote:
--
> Example, IMHO adding a header and footer to a document should be
> something done towards the end of a pipeline, just before serialization,
> not at the beginning, especially where long transforms are involved.
Here's a snippet from one of my sitemaps. It shows using aggregation to add XHTML content
to its correct place in the page, as the last step before serialization. The layout.3hf.xsl
(3hf stands for 3-column, header and footer) just xsl-copies the XHTML content to
the right place on the layout tables/divs, and is agnostic as to which kind
of content is used.
<map:match pattern="">
<map:aggregate element="page">
<map:part src="cocoon:header/frontPage"
element="layout-header" />
<map:part src="cocoon:mainMenu"
element="layout-leftbar" />
<map:part src="cocoon:sectionMenu/frontPage"
element="layout-rightbar" />
<map:part src="cocoon:footerMenu"
element="layout-footer"/>
<map:part src="cocoon:rootPageContent"
element="layout-content" />
</map:aggregate>
<map:transform src="stylesheets/layout.3hf.xsl"/>
<map:serialize />
</map:match>
--
Sergio Carvalho
---------------
sergio.carvalho@acm.org
If at first you don't succeed, skydiving is not for you
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: Some comments on Cocoon 2.0b2
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Carsten!
On Tue, 24 Jul 2001, Carsten Ziegeler wrote:
> > Stefano Mazzocchi wrote:
> >
> > ...
> > 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".
> >
> > Suppose you have something like this:
> >
> > generator -> layout page
> > transformer -> aggregator
> >
> If I understand you right, you can already do this by simply using the
> generator you want and then using the CIncludeTransformer, or did I miss
> a point?
This is amazing deja-vu, I was thinking about this just yesterday.
Yesterday I was looking at the uses of aggregation, thinking it might
be useful in our project. The idea behind it sounds great, but in
practice I came up against some concerns.
Take the simplest case - we have many HTML pages in our application
which have 'headers' and 'footers', as most commercial applications
probably do. Currently this is solved by included xsl templates, which
are called in each html page before serialization.
I thought aggregation would help here, removing the need to have these
templates included and called, but after thinking about it for a while
I unded up a little confused about whether aggregation could help.
The keypoint I think is that aggregation solves the problem of
aggregating multiple data sources together (which is extremely useful),
but when one wants to aggregate multiple presentation components
together it's difficult.
Example, IMHO adding a header and footer to a document should be
something done towards the end of a pipeline, just before serialization,
not at the beginning, especially where long transforms are involved.
We have some pipes where data is generated, created and then either
formatted into html or csv. To aggregate the html part is difficult as
we have to carry the header and footer markup all the way from
generation through each transform, and then either use or discard it
based on the final transform before serialization.
It would be much better if we could aggregate in the 'header' and
'footer' towards the end of the pipeline. This is kind-of possible
using 2 pipelines, one to create the data, the second (invoked first)
used to aggregate the header/footer together with the data from the
first pipeline.
But, as I said, perhaps I've not understood the full power of how to
use aggregration.
Any comments at all mate ? Is CIncludeTransformer useful for this
purpose ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: Some comments on Cocoon 2.0b2
Posted by Carsten Ziegeler <cz...@sundn.de>.
First of all, congratulations for finishing your thesis successfully!
I think, we all are waiting for your "return" in autumn. But until
then: have nice vacations!
And now to something totally different...
> Stefano Mazzocchi wrote:
>
> I think you guys are doing a great job. From looking at the CVS commits
> and the mail logs this project has never been so healthy and I think I
> can finally say that Cocoon is a project that is going to last,
> community wise.
>
> This, people, is not so obvious as you would expect: I'm talking about
> years in the future, not a few months. After watching many OSS projects
> and bootstrapping a few, I believe that Cocoon has the right balance to
> keep going for a long time, despite the changes in the development team.
>
> This said, feeling very proud of having started all this and feeling
> honored of seeing so many people working actively on such a great
> project, I have some small comments to make on the design decisions that
> were made in my absence.
>
> Of course, not being there when the design decisions were made, I'm
> absolutely happy with the state of the project, I'm just writing you my
> comments that you might find helpful.
>
> If not, well, at least I made myself heard. :)
>
> 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".
>
> Suppose you have something like this:
>
> generator -> layout page
> transformer -> aggregator
>
> now you can have a generator produce the outline of the page and the
> transformer (sort of server-side XInclude for XML Inforsets) produce the
> aggregated content. The layout might use a specific namespace that is
> used to react further namespace behavior on the transformer. For example
>
> <lay:layout xmlns:lay="../cocoon/layout"
> xmlns:agg="../cocoon/aggregate">
> <agg:include agg:src="hello.xml" agg:ns="http://www.blah.com"/>
> </lay:layout>
>
> where "hello.xml" is
>
> <page>
> <p>HelloWorld!<p>
> </page>
>
> which leads
>
> <lay:layout xmlns:lay="../cocoon/layout"
> xmlns:agg="../cocoon/aggregate">
> <page xmlns="http://www.blah.com">
> <p>HelloWorld!<p>
> </page>
> </lay:layout>
>
> or something like that.
>
If I understand you right, you can already do this by simply using the
generator you want and then using the CIncludeTransformer, or did I miss
a point?
I agree, you are right, that the implemented content aggregation is not
suitable for creating (I try to avoid the verb generate) dynamic (e.g.
user dependant) content.
But I am not sure, if this is a concern of Cocoon itself. I see it rather
in another module/project (or whatever) which builds on top of Cocoon 2,
e.g. a portal engine using Cocoon 2 as a base.
This engine itself uses the facilities provided and creates a user-dependent
portal, e.g. by implementing a generator does both tasks you mentioned
above.
> 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.
>
When I implemented the cocoon: urls I wasn't sure about this either.
Personally, I think there are only some cases where you need to refer
to the root sitemap from your subsitemap. I think it is very difficult
to maintain as well. If a subsitemap refers to anything on the root sitemap,
you can't change the root sitemap as you would perhaps like to, because
this could brake the subsitemap and therefore your website.
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
> now some RT I'm having in the back of my mind
>
> namespace-reacting trasnformations
> ----------------------------------
>
> There are a bunch of discussions on stylebook/anakia/cocoon these days
> going on and I'm happy that Donald set up the Cocoon-By-Cocoon site
> since it gives us (finally) a serious place to show off our power.
>
> The usual "my DTD is better than yours" flames will start firing as soon
> as we decide what DTD to use.
>
> I heard comments such as "I don't like <link> because I'm used to type
> <a> and I end up with <link src="..."></a>". There is no way we can
> settle this even if we make the tools available to automatize this.
>
> At the same time, it's pretty piece of cake to do transformations
> between tagsets if the semantic meaning is equivalent: if the guy likes
> <a>, that's totally fine for me, as long as it's semantically
> consistent.
>
> For "semantically consistent" I mean that <a> is always used instead of
> <link> and that there is the chance of knowing what that <a> means for
> that particular guy.
>
> Now, suppose you want to generate documentation but you "don't" know in
> advance the schema used for it. All you know is that your pipeline
> expects "docbook" from some point on and you do have some "adaptation
> stylesheets" that transform these simplified but semantically equivalent
> DTDs into docbook.
>
> So, visually, you have:
>
> generator -[docbook]-> transformer -[fo]-> serializer -[pdf]-> client
>
> but if you don't know in advance the markup used you need to adapt
>
> generator -[???]-> adaptor -[docbook]-> ...
>
> There are two ways to identify the semantic context of the document:
>
> 1) DTD/Schema
> 2) namespace
>
> In the firts case, the behavior is straightforward: depending on the
> DTD/Schema, apply a different transformation sheet.
>
> In the second case, if the namespace used is one and only one, the same
> behavior applies. Otherwise, the writing of the stylesheets is more
> complex since it must copy over all the other tags that don't belong to
> the namespace that want to adapt.
>
> Bah, anyway, food for thought.
>
> Ciao.
>
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Some comments on Cocoon 2.0b2
Posted by 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
Re: Some comments on Cocoon 2.0b2
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Tue, 24 Jul 2001, Stuart Roebuck wrote:
> 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).
I like this idea. It would also solve the an issue about using
XInclude to build up XSP code, something possible in Cocoon1 but not
Cocoon2.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Some comments on Cocoon 2.0b2
Posted by Stuart Roebuck <st...@adolos.co.uk>.
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