Eric van der Vlist wrote:
> I should have given more context about what I am trying to achieve, > sorry for that.
> Second, I'd like to use the technique I have described as > "style-free stylesheets" > http://www.xml.com/pub/a/2000/07/26/xslt/xsltstyle.html and give the > ability to the creators of the pages to define the content of their > pages using building blocks defined in the page flows and pipelines. > > That's why, instead of aggregating the search result and the page > template in the pipeline definition, I'd like to pull the search > result into the page template in the XSLT transformation. > > Technically, that may seem not a big deal but in one case the > creator or editor of a web page needs to modify the pipeline and in > the other case he has just to edit his/her page. > > I could generate the pipeline definition dynamically from the layout > page (ie, seeing that the author wants to include a search result, > create the pipeline that does the aggregation), but wouldn't it be > quite heavy? > > Being able to access to the output of a pipeline in my XSLT > transformation would be soooo much simpler :) ...
Eric, as this may interest other people, I provide below a translation of the email in French sent to [EMAIL PROTECTED] on the subject:
I understand the idea very well. You can see this pull approach as "implementing a tag library", a terminology borrowed from JSP but that makes sense here, where each tag is interpreted. Here (in the Cocoon version of your site), the tag implementation is done in XSLT and calls a pipeline using the document() function from XSLT and the "cocoon:" protocol. The resulting XML document (possibly transformed) is included in the output. We can consider the following questions to see how this can be done with Presentation Server:
1. How to easily implement a tag library where each tag returns an XML document.
2. How to make available to the implementation of a tag library resources declared in the "sitemap".
With Presentation Server, there is no "sitemap" a la Cocoon per se. The Page Flow declares "pages" accessible from the outside (through HTTP), and not pipelines. It does declares a site map if you will, but it is completely independent from the pipelines. Those are simply XPL resources on disk for example, just like XSLT stylesheets are. We can imagine at least two strategies:
1. Like with Cocoon, calling pages declared in the Page Flow. This is not possible for now except with the "http:" protocol, which is inelegant and inefficient, and further poses problems like the gneration of a correct URl with host, port, context, etc. You could however implement a protocol to access the PFC (discussed a little bit below).
2. Call any pipeline. The benefit: any pipeline available as a resource can be called. The drawback: the available pipelines are not declared in a central way, as is the case with Cocoon.
I had a similar challenge with Presentation Server when I created a set of "tags" to display images, which requires calling a database. The solution I choose consisted in dynamically generating a pipeline with XSLT, based on the initial document (your XHTML + tags document). The generated pipeline depends on said tags, and calls other pipelines in turn. For example, if you have:
<xhtml>
<body>
<my:image id="123"/>
<br/>
<my:image id="456"/>
</body>
</xhtml>You would dynamically create with XSLT a pipeline like:
<p:config> <p:param name="input-document" type="input"/> <p:param name="output-document" type="output"/>
<p:processor name="oxf:pipeline">
<p:input name="config" href="oxf:/backend/find-image.xpl"/>
<p:input name="image-id" href="aggregate('image-id', #input-document#xpointer(string(//my:image[1]/@id)))"/>
<p:output name="image-info" id="id1"/>
</p:processor>
<p:processor name="oxf:pipeline">
<p:input name="config" href="oxf:/backend/find-image.xpl"/>
<p:input name="image-id" href="aggregate('image-id', #input-document#xpointer(string(//my:image[2]/@id)))"/>
<p:output name="image-info" id="id2"/>
</p:processor>
<p:processor name="oxf:xslt">
<p:input name="config">
<xsl:transform>
<!-- With XSLT, replace tags with results from pipelines -->
<!-- XSLT is not necessarily the most efficient way to implement this aggregation, but it works -->
<!-- ... -->
</xsl:transform>
</p:input>
<p:input name="data" href="aggregate('results', #id1, #id2)"/>
<p:output name="data" ref="output-document"/>
</p:processor>
</p:config>
BTW, if the input XHTML document is static, thanks to the caching mechanisms, the pipeline definition, although dynamically generated with XSLT, will be cached as well. The pipeline execution however can be supposed non-cacheable since it calls a pipeline, find-image.xpl, which likely depends on the contents of an external database.
If the problem consists of creating a tag library which calls pipelines, you could imagine something like this:
<xhtml>
<body>
<my:pipeline href="oxf:/my-pipeline-1.xpl"/>
<br/>
<my:pipeline href="oxf:/my-pipeline-2.xpl"/>
</body>
</xhtml>Supposing to simplify that by convention each pipeline has a "data" output, you generate the following pipeline:
<p:config> <p:param name="input-document" type="input"/> <p:param name="output-document" type="output"/>
<p:processor name="oxf:pipeline">
<p:input name="config" href="oxf:/my-pipeline-1.xpl"/>
<p:output name="data" id="id1"/>
</p:processor>
<p:processor name="oxf:pipeline">
<p:input name="config" href="oxf:/my-pipeline-2.xpl"/>
<p:output name="data" id="id2"/>
</p:processor>
<p:processor name="oxf:xslt">
<p:input name="config">
<xsl:transform>
<!-- With XSLT, replace tags with results from pipelines -->
<!-- XSLT is not necessarily the most efficient way to implement this aggregation, but it works -->
<!-- ... -->
</xsl:transform>
</p:input>
<p:input name="data" href="aggregate('results', #id1, #id2)"/>
<p:output name="data" ref="output-document"/>
</p:processor>
</p:config>
We agree that this mechanism is a little heavy. You could imagine, without modifying Presentation Server, something smarter, based on an XML descriptor that would configure the tag library. This way, the tag interpreter would be generic. For example, the configuration could be like this:
<tag-library>
<tag>
<element name="my:image"/>
<pipeline href="oxf:/backend/find-image.xpl" output="data"/>
</tag>
<tag>
...
</tag>
</tag-library>Missing from this example is a syntax to pass parameters to the pipeline if needed, probably based on the tag attributes and/or its body (JSP terminology).
A few other random ideas:
o The interpreter can be placed in the epilogue.
o The question of implementing a protocol a la "cocoon:", maybe a "pfc:" protocol, remains open.
o To make it easier to write the interpreter and avoid creating a dynamic pipeline, you could create XSLT functions:
1. One to call a random pipeline. 2. One to call a Page Flow page.
Using functions instead of a protocols has some benefits, like allowing passing more complex parameters, such as sequences of XML documents to pass to pipelines, or XForms instances to pass to PFC pages.
For now, save for spending time modifying Presentation Server (and we need a little more time to solve some architectural questions), I suggest implementing a version of this tag interpreter that calls pipelines and implements the "pull" strategy.
> Avec PresentationServer, je pensais trouver la m�me fonctionnalit� > avec la protocole "oxf:", mais ce n'est pas le cas.
The "oxf:" works as an abstraction for access to "resources", i.e. for example to abstract protocols like "file:", "http:", or others like JAR or WAR resources, or through WebDAV (through Slide). Each protocol is handled by a separate "resource manager". You could implement a resource manager to access the PFC, but while you can cascade resource managers, there is no way with the "oxf:" protocol to discriminate between resource managers. We would have to modify the way the "oxf:" protocol works, or create a new protocol like "pfc:".
> Un contournement consiste � utiliser le protocole http mais je ne > suis pas certain qu'il n'y ait pas des cons�quences s�rieuses au > niveau des performances.
Correct, as mentioned above, this is not a very good solution.
> Un autre contournement consiste � g�n�rer dynamiquement le pipeline > qui va constituer la page. Est-ce celui que tu conseillerais pour > faire ce que je veux et est-ce que cela ne va pas consid�rablement > alourdir les choses?
It is definitely heavier, but once the interpreter programmed, you can see it as a generic component that will be modified only rarely. From the point of view of runtime performance, this won't be immediately optimal, but you could in a second phase, after XPL + XSLT prototyping, create a Java interpeter implemented as a processor. This should be much more efficient than the XPL + XSLT combination proposed above.
I am sure that other approaches can be suggested! This is interesting because the problem is generic (see JSP).
I think such a taglib-based approach may be used to solve Stephan's question in an earlier email:
> I have a conceptual question. Our application uses a lot of database > queries we have grouped into logical groups and created XPL for > them, about a dozen. Now we need to retrieve the information in > various constellations, depending on the initial request. How can I > combine the results of 3 or 4 XPL into a single XML for further > processing?
-Erik
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ orbeon-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/orbeon-user
