Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
<snip/>
> > To conclude: I belive that xml based selection together with
transformers
> > with side effects can considerably reduce the need for actions and that
it
> > would make it much easier to write Cocoon aplications that takes xml
input.
>
> I think you expressed a very valid point of the need for pipe-based
> selection.
:)
> I have two concerns:
>
> 1) a pipe-selector is really a selector or is it something else?
>
> [translated operationally: should we come up with another interface?]
I am not an expert in the inner workings of the sitemap, so what follows
might not work at all:
The pipe-selector (ideas about a better name?) would look something like
this:
<pipe-selector type="xpath">
<when test="expr1">
<!-- pipeline fragment -->
</when>
<when test="expr2">
<!-- pipeline fragment -->
</when>
...
<otherwise>
<!-- pipeline fragment -->
</otherwise>
</pipe-selector>
The general idea is that the pipe-selector buffers it input in e.g. a
DOM-tree, then the tests can be applied to the buffered input. The pipeline
fragment in the first when clause where the test succeed is then feeded with
the buffered input, and its output is send to the pipeline component after
the pipe selector.
How can this be implemented?
The pipe-selector is a transformer (i.e. implements the transformer
interface) extended with a method that lets the sitemap constructor send an
object to the pipe-selector that takes care of the tests and the pipeline
fragment construction for the selected when clause in the pipe-selector.
The actual tests can implement the selector interface if it is ok to put the
DOM-tree with buffered input in the objectModel. A possible issue with this
is that the tests in the selector are performed after that the whole
pipeline is constructed. This might give the unintuitive effect that
components later in the pipeline that effects the objectModel and is
executed during sitemap construction time are executed before the test in
the pipe-selector.
The sitemap stylesheet constructs a class for each pipe-selector instance in
the sitemap. This class contains a method that returns a EventPipeline. The
method executes the tests and constructs and returns an EventPipeline for
the first when clause that succeed. The EventPipline starts with a generator
puts the DOM-tree in the objectModell in a DOMStreamer.
class PipeSelectorInternalPipeN01234 {
public EventPipeLine constructPipe(SitemapRedirector redirector,
Environment environment,
List listOfMaps) { ... }
}
The code in sitemap_xmap for constructing the pipeline that contains a
pipe-selector is like that for any pipeline that contains a transformer,
with the difference that the "pipe-selector transformer" is given an
instance of its PipeSelectorInternalPipe class.
The algoritm for the PipeSelector is:
* Its input is connected to a DOMBuilder.
* The DOM-tree is put in the objectModel.
* The constructPipe(...) method of the PipeSelectors
PipeSelectorInternalPipe class is executed.
* The returned EventPipeline is connected to the output of the PipeSelector
and the EventPipelines process method is called.
I hope that the description above is comprehensible.
> 2) how does this impact performance? how does this impact caching?
>
> [the first impacts the system usage, the second the interface of
> Selectors or PipeSelectors]
The simplest way to implement cashability is to base the cash key generation
on _all_ of the pipeline fragments in the when clauses. This is fairly
unsatisfying as it implies the construction of all of the pipeline fragments
instead of only the one that is selected. It will also decrease the
possibility to cash the PipeSelector and lead to unnecesary recalculation
based on changes in "when clauses" that was not selected. The problem is
that when the generateKey() method is called it is not known what "when
clause" that will be choosen. If we however had a method like
generateKey(key), where "key" is the hash key for the pipeline fragment
before the PipeSelector, "key" uniquely determines the input to the
PipeSelector and thus what "when clause" that will be selected, this
information: the map from key to "when clause", could be stored and the used
to compute the cach key for the PipeSelector only based on the pipeline
fragment in the _selected_ when clause.
Performance: it would of course better to not be forced to store the
SAX-events in DOM-tree, but I do not see much choice. The main use for the
PipeSelector will probably be to make selection based on XML input to Cocoon
and on the output from transformers with side effects, I would guess that
for these cases it will most of the time be quite small documents. Besides
the need for buffering I do not think there should be any sources to
performance botlenecks in a PipeSelector, but I do not know enogh about the
internals of Cocoon to know for sure.
What do you think?, would something along this lines work?
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
