cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck ...@adolos.com>
Subject Re: [C2] Merging pipelines into a new pipeline
Date Thu, 21 Sep 2000 15:22:38 GMT
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.

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

Apologies if this doesn't make sense - I have been accused of talking in  
riddles at times!

Stuart.

Mime
View raw message