Stefano Mazzocchi wrote:
<snip/>
> My impression is that pipe-aware selection is 'forcing' metadata to pass
> 'thru' the pipeline while it doesn't really make sense to do so.
>
> So, IMO, there must be some transformers that obtain the required
> selection information from the pipeline, place it somewhere else
> (probably someplace in the object model) and have the selectors look at
> those 'parallel signals' without having to mess with the pipeline.
>
> So, I restate my -1 on pipe-aware selection and I propose the creation
> of a 'parallel transport layer' between components that is based on
> objects and not SAX events.
>
> NOTE: this has nothing to do with implementation issues even if, at the
> end, will probably result in better performance because 'early
> optimization is the root of evil' but 'using antipatterns is even
> worse!' :)
>
> Fire at will.
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.
So, now we have identified three possible classes of selctors:
1. Ordinary selectors - selects on information gathered before pipeline
construction time.
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).
3. Pipe content dependent selectors - selects on the content in the
SAX-stream from the previous pipeline step.
Is 2. a correct description of what you propose above?
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.
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.
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?
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.
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
