Le lundi 31 janvier 2005 � 15:41 +0100, Erik Bruchez a �crit :
> 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 ;-)
Hmmm... this is only an example (maybe poorly chosen, sorry if that's
the case).
What I wanted to illustrate is the more general issue coming from the
current behaviour of processors without connected outputs and I could
have given the same kind of examples with XML databases updates, deletes
and inserts.
> 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?
The point I wanted to make is that this is difficult right now because
of that behaviour!
My proposal to make that easier is:
* A processor (or pipe) this isn't the null serializer is never
executed at all (its init method isn't called) if it has no
output or if none of its output is connected.
* An output (named "control" or "command", "action" or whatever)
is added to each of the processors that have currently no
outputs. This output returns either an <empty/> element or any
processing information that could be useful (for a database
update, that could be a number of rows, ...).
* Optional: change the name of the null serializer to something
closer to the pipe metaphor (for instance "sink" or "ground"
-more "electrical").
Assuming these modifications, by not-so-well-chosen-example becomes 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>
Now, I wouldn't want to pay too much attention to this example.
What I really mean is that I am convinced that the "pipe semantics"
would be much cleaner with these modifications and that, by choosing
which outputs would be connected to the sink we would control the flow
within the pipe exactly like in real pipelines or electrical circuits.
> 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.
No, you do well by bringing them to my attention! they seem pretty
useful too...
> 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.
I agree that there are many other ways to do it and had even provided
one myself :-) ...
Again, I am reasoning out of the scope of this example only and
proposing an alternative to the current behaviour of the "processors
with no connected outputs" behaviour that hasn't convinced me
yet :-) ...
To me, a pipe without a connected output is and should remain a dead
end!
Recognising it is not only more natural, but can also let us leverage on
most powerful physical effects, including the ones on which
semiconductors are based...
Eric
--
Curious about Relax NG? Read my book online.
http://books.xmlschemata.org/relaxng/
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
-------------------------------------------------------
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
