cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [C2] Merging pipelines into a new pipeline
Date Wed, 20 Sep 2000 23:36:39 GMT
Stuart Roebuck wrote:
> 
> On Wednesday, September 20, 2000, at 12:03 AM, Stefano Mazzocchi wrote:
> 
> > Stuart Roebuck wrote:
> > >
> > > Can anyone point me in the right direction with this little problem.  I
> > > suspect there is an elegant solution in Cocoon 2, but I haven't found it in
> > > my trawling of the documentation and draft sitemap documents.
> > >
> > > I basically want to merge the output (serialized) of two or more pipelines
> > > as the input (generator) of another.
> > >
> > > Currently I do it by creating a dummy.xml file as the generator for a
> > > pipeline containing an XSLT translator which has code of the form:
> > >
> > > <xsl:template match="dummy">
> > >     <new-group>
> > >         <xsl:apply-templates
> > > select="document('http://localhost:8080/context/pipe1.xml')/group/*" />
> > >         <xsl:apply-templates
> > > select="document('http://localhost:8080/context/pipe2.xml')/group/*" />
> > >     </new-group>
> > > </xsl:template>
> > >
> > > This works, but it's not exactly elegant / scaleable / etc.
> > >
> > > If I could do something like:
> > >
> > >    <xsl:apply-templates select="document('cocoon://pipe1.xml')/group/*"
/>
> > >    <xsl:apply-templates select="document('cocoon://pipe2.xml')/group/*"
/>
> >
> > Hmmmm, just stroke me, what about simply
> >
> >   <xsl:apply-templates select="document('pipe1.xml')/group/*" />
> >
> > then
> >
> >   <xsl:apply-templates select="document('file:///pipe1.xml')/group/*" />
> >
> > if you wanted a file on the file system?
> >
> > That way we don't have to extend URL and makes perfect sense to consider
> > the cocoon pipeline the current context.
> >
> > What do you think?
> 
> I think this still clashes with the model/view separation.  My
> understanding is that the assumption in all XSLT and XSP is that the local
> file system is the current context (by default) there is no need to know
> what is in the sitemap to do processing.  To make the sitemap the current
> context would seem to imply that the view and model are not intended to be
> separate.

I disagree: the sitemap enforces the URI contracts, when you do
something like

 <xsl:apply-templates select="document('this/that')/group/*"/>

or 

 <whatever xinclude:href="this/that"/>

you are calling the resource identified by the "this/that" uniform
identifier (URI, that is).

The concerns are separated by the presence of the sitemap, and there is
no design difference between

 <xsl:apply-templates select="document('this/that')/group/*"/>
 <xsl:apply-templates
select="document('http://host/context/this/that')/group/*"/>
 <xsl:apply-templates
select="document('http://www.mystuff.com/this/that')/group/*"/>

only implementation details.
 
> Purely from a users viewpoint (ie. completely ignoring the coding
> implications) I think I would currently favour something like:
> 
> <xsl:apply-templates select="document('resource:resourcename')/group/*" />
> 
> ...to access a (probably non-serialised) stream directly from a 'resource'
> in the sitemap, and:
> 
> <xsl:apply-templates select="document('sitemap:externalfilename.xml')/group/*" />
> 
> ...to access the (probably serialised) stream from a pipeline in the sitemap.

A sitemap "resource" is a sitemap "pipeline".

And a sitemap "resource" is identified mainly by URI, so your model has
the exact same problems mine would have.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message