[EMAIL PROTECTED] wrote
The fix is one short function added to
PipelineEventComponentProcessingNode and called in the line that sets
the Parameters of the three child classes. Maintenance would be easy.
No, it is not - fixing it this way would cause a lot of trouble and
break the whole
On Feb 20, 2008, at 7:40 PM, Joerg Heinicke wrote:
That's why I'm strongly against adding this functionality to the
sitemap.
+1
(I have held back this mail (for nearly 24 hours) so that others could
form their own view. But it seems not too many people are
interested ...)
Well, beside
I must state, I never really thought of matchers and selectors as applicable to
non-primary components.
I think, I can imagine tons of reasons causing such extension of current
functionality to grow into a nightmare of semantic changes
and incompatibilities.
However, this request and the
On 19.02.2008 21:17, [EMAIL PROTECTED] wrote:
Compare these examples:
map:select
map:when test=first
map:transform
map:parameter name=choice value=first/
/map:transform
/map:when
map:otherwise
map:transform
map:parameter name=choice value=other/
On Wed, Feb 20, 2008 at 7:40 PM, Joerg Heinicke [EMAIL PROTECTED] wrote:
On 19.02.2008 21:17, [EMAIL PROTECTED] wrote:
Compare these examples:
map:select
map:when test=first
map:transform
map:parameter name=choice value=first/
/map:transform
On 20.02.2008 21:04, [EMAIL PROTECTED] wrote:
Writing a reusable InputModule that can handle:
if(resource1.exists()){ return parameter1;}
else if(resource2.exists()){return parameter2;}
else if(resource3.exists()){return parameter3; }
...
else return finalparameter;
is possible.
Classes extending SimpleParentProcessingNode decide which children to
process and call invoke() on those children.
Classes extending PipelineEventComponentProcessingNode assume all
children are configuration for the parent node. Any children not
understood by the component are ignored.
Compare
