Daniel Fagerstrom wrote:
>
> Yes, I think I agree, it is more elegant to have a separate path for
> metadata. I still have to ponder the consequences, but it seem to be a good
> way to go.
It has been noted that both things might be needed in different
situations, so, if we were to have pipe-aware selection, I would also
like to have an explicit way for components to 'communicate' without
having to force them to use the pipeline.
This admittedly creates a multipath (there are saveral ways that
components can communicate between each other) but the paths are
sufficiently different to make it easy to indicate when each one of them
should be used.
> So, now we have identified three possible classes of selctors:
> 1. Ordinary selectors - selects on information gathered before pipeline
> construction time.
yes
> 2. Pipe state dependent selectors - selects on information in e.g. the
> object model or request attributes, set by earlier steps in the pipeline
> (e.g. generators and transformers).
yes
> 3. Pipe content dependent selectors - selects on the content in the
> SAX-stream from the previous pipeline step.
yes
And I agree that we should probably have all three of them.
> Is 2. a correct description of what you propose above?
yes, correct.
> Use cases
> ---------
>
> It might be a good idea to summarize the use cases where ordinary selectors
> IMHO is not enough, (or at least lead to clumsy solutions), and where pipe
> state or content dependent selectors could be useful.
>
> The main idea is that we have XML-input (or input that is transformed to XML
> early on). This input can be from e.g. XForms like input handling as in
> Ivelins and Torstens proposals, from SOAP request or from WebDAV messages.
> As this is XML-data it seem natural to put it in a pipeline.
Agreed.
> After having put the XML-data in the pipeline there are several things that
> we might want to do with the data. First it is generally a good idea to
> validate the data, this can be done in a validation transformer, IIRC Ivelin
> and Torsten have developed such a thing. If the data is invalid, the user
> should get feedback on this and a possibility to correct it and otherwise
> the data can be send to the next step in the pipeline. Later in the pipeline
> there might be a transformer with side effects: a WritableSourceTransformer,
> an SQLTransformer or maybe a transformer that interacts with some business
> objects. In all these cases things might go wrong and if we want customized
> error messages, pipe state (or content) dependent selectors are needed.
>
> In the above examples, the transformers need to inform later pipeline steps
> about the result of the computation (the content) and if it was successful
> (metadata). Possible ways to do this is: putting the metadata in the object
> model, putting the metadata within the content, or aggregate the metadata
> and the content as xml with an wrapper element as in SOAP.
>
> ex on aggregation:
> <input>
> <header>
> <!-- metadata -->
> </header>
> <body>
> <!-- content -->
> </body>
> </input>
>
> In the abovementioned use cases I tend to agree that putting metadata in the
> object model is the most elegant solution, most "Cocoon style" and probably
> most efficient. Possible disadvantages are, that SOAP messages already put
> metadata in the xml-input (as Ivelin describes in another post) and I think
> the same applies to WebDAV messages. Writing xslt-transformers that handle
> metadata also becomes more complicated (and might require extension
> functions), if metadata is put in the object model.
Granted.
> Is this everything there is to it?
>
> No, I think a very important use-case are wizards (or multi-page forms),
> where the next set of questions typically are conditioned on what you have
> answered this far. Consider e.g. an program installation wizard, where you
> get a number of extra forms to fill in if you choose customized
> installation. On the company where I work we have developed an interview
> management system, it is not developed in web-technology, but translated to
> such concepts, the next question in the interview is based on
> xpath-selection on the answer from the previous question and the session
> state that contains the answer from earlier questions. These simple concepts
> are very powerful, the system have been used to manage large number of
> interviews in many project during nearly ten years, and some of the
> interviews have been extremely complex. Anyhow, IMHO these are important use
> cases where selection is based on input content rather than metadata.
>
> So, what do you think?
As I said, I think we need all three of these selection capabilities and
even if this creates a multipath.
> Implementation note
> -------------------
>
> A pipe state dependent selector is easy to implement based on my pipe-aware
> selection contribution. It is just to write an ordinary selector that checks
> an object model or request attribute, and letting it implement the marker
> interface PipeAware, everything else that is needed is already in the
> implementation.
Yes, implementation doesn't concern me.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
