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 discuss
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 f
[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 sitemap
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. T
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:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > And:
> >
On 19.02.2008 21:17, [EMAIL PROTECTED] wrote:
Compare these examples:
And:
Differentiating the elements may make sense to Cocoon devs, but is not
obvious to Cocoon user