I understand that doing what you are trying to do the way you are doing it is verbose and appears difficult, but I don't quite understand why you want to do it that way ;-)
That's note quite true of course. If I follow you reasoning well, it is really just that you want to either:
1) Read an output and make sure there is no serialization
2) Do not read that output (so either not read any output at all, or read a different output) and do serialization
I have to reckon that doing this appears to be difficult with the current processing model. What about other solutions?
You decide to execute a given pipeline based on a URL or an action. What I would naturally do is, in each such pipeline, separate the flow into:
1) Retrieve the raw data (get-raw-data.xpl, if you wish)
2) Serialize it into the format selected, either directly, or by calling a second pipeline (serialize-to-[xml|html|...].xpl)
Before I go further, I wanted to make sure that you were aware of the converters in Presentation Server. Those behave like serializers, except they have an output containing the plain binary or text data.
So your initial pipeline could simply be something like:
<p:config>
<p:param name="data" type="input"> <p:param name="plain-data" type="output"> <p:param name="xml" type="output"> <p:param name="html" type="output">
<p:processor name="oxf:identity">
<p:input name="data" href="#plain-data"/>
<p:output name="data" ref="data"/>
</p:processor> <p:processor name="oxf:xml-converter">
<p:input name="data" href="#data"/>
<p:input name="config">...</p:input>
<p:output name="data" ref="xml"/>
</p:processor> <p:processor name="oxf:html-converter">
<p:input name="data" href="#data"/>
<p:input name="config">...</p:input>
<p:output name="data" ref="html"/>
</p:processor></p:config>
Then, you can pull each of the outputs, and for example do this:
xml.xpl: <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline"; xmlns:oxf="http://www.orbeon.com/oxf/processors";> <p:processor name="oxf:pipeline"> <p:input name="config" href="multi.xpl"/> <p:output name="xml" id="xml"/> </p:processor> <p:processor name="oxf:http-serializer"> <p:input name="data" href="#xml"/> <p:input name="config">...</p:input> </p:processor> </p:config>
There is a drawback, which is that you are doing some work (actual HTTP serialization) outside of multi.xpl, so that may not be the answer to your initial question. But it looks a little bit like your initial solution in that you have a centralized pipeline producing the output, whether XML, XHTML, text, or XHTML, and then you use a pull mechanism from the outside that also determines what conversion is done.
Now you could do this with the good old serializers as well:
xml.xpl: <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline"; xmlns:oxf="http://www.orbeon.com/oxf/processors";> <p:processor name="oxf:pipeline"> <p:input name="config" href="multi.xpl"/> <p:output name="plain-data" id="plain"/> </p:processor> <p:processor name="oxf:xml-serializer"> <p:input name="data" href="#plain"/> <p:input name="config">...</p:input> </p:processor> </p:config>
Or, if serializing to XML is harder than just calling one processor:
xml.xpl: <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline"; xmlns:oxf="http://www.orbeon.com/oxf/processors";> <p:processor name="oxf:pipeline"> <p:input name="config" href="multi.xpl"/> <p:output name="plain-data" id="plain"/> </p:processor> <p:processor name="oxf:pipeline"> <p:input name="data" href="#plain"/> <p:input name="config" href="serialize-to-xml.xpl"/> </p:processor> </p:config>
With something like this last solution, you have a good separation between the operations of producing the data, and converting it / serializing it.
-Erik
Eric van der Vlist wrote:
> Hi,
>
> Le vendredi 28 janvier 2005 � 12:01 +0100, Eric van der Vlist a �crit :
>
> I am not completely happy with the pipe I have proposed the other day:
>
>
>><p:config>
>>
>><p:param name="data" type="input">
>><p:param name="target" type="input">
>><p:param name="data" type="output">
>>
>><p:choose href="#target">
>> <p:when test="target='xml'"> xml serializer </p:when>
>> <p:when test="target='html'"> html serializer </p:when>
>></p:choose>
>>
>><p:processor name="oxf:identity">
>> <p:input name="data" href="#data"/>
>> <p:output name="data" ref="data"/>
>></p:processor>
>>
>></p:config>
>
>
> It's kind of mixing to different paradigms: the target input that
> triggers the choose and the data output that pulls the output when no
> branches of the choose are matched.
>
> Since we've more or less discarded the target approach, I think that it
> would be better if we could rely of the pull approach to choose the
> branch as well.
>
> That means, being able to define a pipe (let's call it "multi.xpl") from
> which we could either pull data for further processing or pull a XML,
> HTML or text serialisation.
>
> In other words, a pipe that we could use as in the following
> page-flow.xml:
>
> <page id="default" path-info="/tests/default" view="multi.xpl"/>
> <page id="xml" path-info="/tests/xml" model="xml.xpl"/>
> <page id="html" path-info="/tests/html" model="html.xpl"/>
> <page id="text" path-info="/tests/text" model="text.xpl"/>
>
> with
>
> text.xpl:
> <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline";
> xmlns:oxf="http://www.orbeon.com/oxf/processors";>
> <p:processor name="oxf:pipeline">
> <p:input name="config" href="multi.xpl"/>
> <p:output name="text" id="text"/>
> </p:processor>
> <p:processor name="oxf:null-serializer">
> <p:input name="data" href="#text"/>
> </p:processor>
> </p:config>
>
> xml.xpl:
> <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline";
> xmlns:oxf="http://www.orbeon.com/oxf/processors";>
> <p:processor name="oxf:pipeline">
> <p:input name="config" href="multi.xpl"/>
> <p:output name="xml" id="xml"/>
> </p:processor>
> <p:processor name="oxf:null-serializer">
> <p:input name="data" href="#xml"/>
> </p:processor>
> </p:config>
>
> and html.xpl:
> <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline";
> xmlns:oxf="http://www.orbeon.com/oxf/processors";>
> <p:processor name="oxf:pipeline">
> <p:input name="config" href="multi.xpl"/>
> <p:output name="html" id="html"/>
> </p:processor>
> <p:processor name="oxf:null-serializer">
> <p:input name="data" href="#html"/>
> </p:processor>
> </p:config>
>
> As you see, I am using the same pipe and in the first case
> (/tests/default) I am pulling a document through its "data" output to
> apply the epilogue while in the three other cases I am pulling the
> "text", "xml" and "html" outputs into a null serializer to provoke a
> text, xml or html serialization.
>
> This requires that these serializations are not done automatically and
> that would be very easy if there wasn't this rule to call the init
> method of each processor without output.
>
> In fact, that's doable right now, but not as straightforward as one
> could hope:
>
> multi.xpl:
> <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline";
> xmlns:oxf="http://www.orbeon.com/oxf/processors";>
> <p:param name="data" type="output"/>
> <p:param name="xml" type="output"/>
> <p:param name="html" type="output"/>
> <p:param name="text" type="output"/>
> <p:processor name="oxf:identity">
> <p:input name="data" href="index.xhtml"/>
> <p:output name="data" id="document"/>
> </p:processor>
> <p:processor name="oxf:pipeline">
> <p:input name="doc1" href="#document"/>
> <p:input name="config">
> <p:config>
> <p:param name="doc1" type="input"/>
> <p:param name="pull1" type="output"/>
> <p:processor name="oxf:xml-serializer">
> <p:input name="config">
> <config/>
> </p:input>
> <p:input name="data" href="#doc1"/>
> </p:processor>
> <p:processor name="oxf:identity">
> <p:input name="data">
> <empty/>
> </p:input>
> <p:output name="data" ref="pull1"/>
> </p:processor>
> </p:config>
> </p:input>
> <p:output name="pull1" ref="xml"/>
> </p:processor>
> <p:processor name="oxf:pipeline">
> <p:input name="doc2" href="#document"/>
> <p:input name="config">
> <p:config>
> <p:param name="doc2" type="input"/>
> <p:param name="pull2" type="output"/>
> <p:processor name="oxf:html-serializer">
> <p:input name="config">
> <config/>
> </p:input>
> <p:input name="data" href="#doc2"/>
> </p:processor>
> <p:processor name="oxf:identity">
> <p:input name="data">
> <empty/>
> </p:input>
> <p:output name="data" ref="pull2"/>
> </p:processor>
> </p:config>
> </p:input>
> <p:output name="pull2" ref="html"/>
> </p:processor>
> <p:processor name="oxf:pipeline">
> <p:input name="doc3" href="#document"/>
> <p:input name="config">
> <p:config>
> <p:param name="doc3" type="input"/>
> <p:param name="pull3" type="output"/>
> <p:processor name="oxf:text-serializer">
> <p:input name="config">
> <config/>
> </p:input>
> <p:input name="data" href="#doc3#xpointer(/xhtml:html/xhtml:body)"
> xmlns:xhtml="http://www.w3.org/1999/xhtml"/>
> </p:processor>
> <p:processor name="oxf:identity">
> <p:input name="data">
> <empty/>
> </p:input>
> <p:output name="data" ref="pull3"/>
> </p:processor>
> </p:config>
> </p:input>
> <p:output name="pull3" ref="text"/>
> </p:processor>
> <p:processor name="oxf:identity">
> <p:input name="data" href="#document"/>
> <p:output name="data" ref="data"/>
> </p:processor>
> </p:config>
>
> Why is that so verbose to implement that?
>
> My new take on the issue is that instead of this rule to call the init
> method of processors without connected outputs, we could on the contrary
> make sure that each processor as at least an output that can be used to
> pull actions.
>
> If you go back to real pipelines, if you want that something happens,
> you need to provide an output to your pipe, otherwise they won't be any
> circulation of fluid. If you take the metaphor or an electric circuit,
> you need to provide a difference of potential to have a current.
>
> In the case of XPL, I am beginning to think that the issue we have is
> due to the fact that are ignoring that simple fact and wanting to insure
> that fluids will flow without output or that there will be a current
> without difference of potential.
>
> We could remove this "not natural" rule and add "action" outputs to the
> serializers and multi.xpl would become as simple as:
>
> <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline";
> xmlns:oxf="http://www.orbeon.com/oxf/processors";>
> <p:param name="data" type="output"/>
> <p:param name="xml" type="output"/>
> <p:param name="html" type="output"/>
> <p:param name="text" type="output"/>
> <p:processor name="oxf:identity">
> <p:input name="data" href="index.xhtml"/>
> <p:output name="data" id="document"/>
> </p:processor>
> <p:processor name="oxf:xml-serializer">
> <p:input name="config">
> <config/>
> </p:input>
> <p:input name="data" href="#document"/>
> <p:output name="action" href="#xml"/>
> </p:processor>
> <p:processor name="oxf:html-serializer">
> <p:input name="config">
> <config/>
> </p:input>
> <p:input name="data" href="#document"/>
> <p:output name="action" href="#html"/>
> </p:processor>
> <p:processor name="oxf:text-serializer">
> <p:input name="config">
> <config/>
> </p:input>
> <p:input name="data" href="#document"/>
> <p:output name="action" href="#text"/>
> </p:processor>
> <p:processor name="oxf:identity">
> <p:input name="data" href="#document"/>
> <p:output name="data" ref="data"/>
> </p:processor>
> </p:config>
>
> In fact, the only processor without output would be oxf:null-serializer
> that would add as the ground in an electric circuit or a sink for a
> pipeline.
>
> Would that make sense?
>
> Eric
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ orbeon-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/orbeon-user
