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 Thu, 21 Sep 2000 16:34:50 GMT
Stuart Roebuck wrote:
> 
> On Thursday, September 21, 2000, at 12:36 AM, Stefano Mazzocchi wrote:
> 
> > 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.
> 
> My feeling is that XSLT exists outwith the Cocoon and sitemap environment,
> and XSLT sheets can be developed and re-used without reference to the
> sitemaps they are applied with/to.  My concern is that using the sitemap to
> 'enforce the URI contract' actually ties the XSLT processing and the
> sitemap into a relationship they are not obligued to have, hence my
> reference to models and views.

Good point.
 
> > > 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.
> 
> I agree.  But I was working on the premise that 'resources' are not served
> 'externally' in the same way as pipline.  So, whilst a pipeline is
> designed to match one or more URIs and those URIs are very dependent on the
> external view of the site, the 'resources' presumably have a single 'id'
> which isn't viewed externally and doesn't need to be changed to suite the
> view of the site.
> 
> So, whilst both 'resources' and 'pipelines' are both pipeline in a
> sitemap, they can potentially serve different roles with the 'resources'
> being analogous to protected methods and 'pipelines' being analogous to
> public methods.  The normal rules and implications in terms of naming and
> API design apply.
> 
> All that said, I guess I'm moving more towards Zvi comments, that the
> sitemap should provide a mechanism for merging inputs.  At present we have
> a bidirectional dependency between sitemap and XSLT sheets.  If we could
> 'push' merged data into a XSLT sheet from the sitemap, rather than
> 'pulling' it from the XSLT sheet, the dependency would become one-way:
> sitemap depends on XSLT sheets.

The problem is that the document() function in XSLT is *clearly* a hack
and should not be used... rather, XInclude should be the way to go.

This makes the aggregation much more elegant, don't you think?

But I agree that a "cocoon:" or "sitemap:" URI protocol is needed to
distinguish between file inclusion and internal pipelines inclusion.

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