You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Rainer Pruy <Ra...@Acrys.COM> on 2008/02/21 14:49:32 UTC
Is there an "url wildcard" selector (equivalent)
Hi,
probably a question with a simple answer.
However, I just failed up to now in getting at it.....
wildcard *matcher* is one of the most used components with cocoon, I'd reckon.
But what to do, when one needs to handle X/c/** and X/** (excluding X/c/**) different?
(At least if the contained components are not "final" (serialize, read))
("X" is an arbitrary path, not having any single path component "c";
while "c" is a simple path component (no "/"))
Using combinations of wildcard macher and simple selector does work, but is quite verbose.
A "not c" pattern is not generally available (decomposing c into positive and negative set patterns
might work, but will be even more writing for c's that include several characters).
Any selector I did miss?
Regards,
Rainer
--
Rainer Pruy
Managing Director
Acrys Consult GmbH & Co. KG
Untermainkai 29-30, D-60329 Frankfurt, Germany
Phone: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com - Email: office@acrys.com
Registered: Frankfurt am Main, HRA 31151
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Tobia Conforto pisze:
> Rainer Pruy wrote:
>> wildcard *matcher* is one of the most used components with cocoon, I'd
>> reckon. But what to do, when one needs to handle X/c/** and X/**
>> (excluding X/c/**) different? At least if the contained components are
>> not "final" (serialize, read)
>
> Cocoon has no URI selector, wildcard or otherwise, probably as some kind
> of deliberate design choice.
>
> This kind of problem is easily solved with Perl-compatible regexps, but
> Cocoon uses the inefficient and less powerful Jakarta Regexp package
> (this is a big gripe of mine, btw) probably for "hysterical raisins."
Patches are always welcome, I think that nobody would mind having new implementation of regexp matcher.
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by Tobia Conforto <to...@linux.it>.
Rainer Pruy wrote:
> wildcard *matcher* is one of the most used components with cocoon,
> I'd reckon. But what to do, when one needs to handle X/c/** and X/**
> (excluding X/c/**) different? At least if the contained components
> are not "final" (serialize, read)
Cocoon has no URI selector, wildcard or otherwise, probably as some
kind of deliberate design choice.
This kind of problem is easily solved with Perl-compatible regexps,
but Cocoon uses the inefficient and less powerful Jakarta Regexp
package (this is a big gripe of mine, btw) probably for "hysterical
raisins."
If it used the native java.util.regex you could match on "^X/c/" and
on "^X/(?!c/)", but alas you're limited to egrep-style regular
expressions, which lack negative lookaheads.
If you don't like the nested simple selector solution, or the
resources solution, you will have to write your own matcher or
selector. Which is not hard at all, by the way. Just extend
AbstractPreparableMatcher or AbstractSwitchSelector, put your class in
WEB-INF/classes and give it a short name in your sitemap.xconf.
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Is there an "url wildcard" selector (equivalent)
Posted by Jasha Joachimsthal <j....@hippo.nl>.
What about placing a matcher for "X/c/**" above/before "X/**"? Or is my thought too simple?
Jasha
-----Original Message-----
From: Rainer Pruy [mailto:Rainer.Pruy@Acrys.COM]
Sent: Thu 21-2-2008 14:49
To: users@cocoon.apache.org
Subject: Is there an "url wildcard" selector (equivalent)
Hi,
probably a question with a simple answer.
However, I just failed up to now in getting at it.....
wildcard *matcher* is one of the most used components with cocoon, I'd reckon.
But what to do, when one needs to handle X/c/** and X/** (excluding X/c/**) different?
(At least if the contained components are not "final" (serialize, read))
("X" is an arbitrary path, not having any single path component "c";
while "c" is a simple path component (no "/"))
Using combinations of wildcard macher and simple selector does work, but is quite verbose.
A "not c" pattern is not generally available (decomposing c into positive and negative set patterns
might work, but will be even more writing for c's that include several characters).
Any selector I did miss?
Regards,
Rainer
--
Rainer Pruy
Managing Director
Acrys Consult GmbH & Co. KG
Untermainkai 29-30, D-60329 Frankfurt, Germany
Phone: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com - Email: office@acrys.com
Registered: Frankfurt am Main, HRA 31151
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by so...@apache.org.
On 3/17/08, Mark Lundquist <lu...@gmail.com> wrote:
> On Mar 17, 2008, at 5:17 PM, Mark Lundquist wrote:
> > You might find this interesting:
> > http://thread.gmane.org/gmane.text.xml.cocoon.devel/68380/focus=68408
> whoops, I meant just this:
> http://thread.gmane.org/gmane.text.xml.cocoon.devel/68380
Read the thread. Good thoughts.
You are correct that Matchers are just a special case of a Selector so
the Selector interface is better than the Matcher interface for your
goals. Selectors already have multiple conditions and "otherwise".
Matchers and most Selectors could be eliminated, and more
functionality gained with a RegexpSelector:
<map:select type="regexp" src="{request:sitemapURI}">
<map:when test="^$|^/$">
<!-- Default with no string -->
</map:when>
<map:when test="^([.^/]*)/([.^/]*)/([.^/]*)$">
<!-- Matches three slash-delimited parts and loads {1}, {2}, and {3} -->
</map:when>
<map:otherwise>
<!-- Anything else -->
</map:otherwise>
</map:select>
The (huge) downside is requiring knowledge of rexexp. An easier
Selector should allow something close to the current system:
<map:select type="match">
<map:when test="">
<!-- Default with no string -->
</map:when>
<map:when test="/">
<!-- Another default for no string -->
</map:when>
<map:when test="*/*/*">
<!-- Matches three slash-delimited parts and loads {1}, {2}, and {3} -->
</map:when>
<map:otherwise>
<!-- Anything else -->
</map:otherwise>
</map:select>
Since either variant would allow src="{AnyInputModule:AnyVariable}",
these two Selectors could replace all the current variations of
Matchers and Selectors. Best is all the needed code exists in the
current classes so creating these Selectors should be easy.
OTOH, the devs seem excited about losing functionality in future
releases. A suggestion that Selectors could be used to choose
parameters inside Generator, Transformer, and Serializer elements met
strong resistance. Aggregators (obviously merging several Generators)
do not share code with Generators so every developer must learn the
hard way that this code does not work:
<map:aggregate element="content">
<map:part type="someGenerator" src="something"/>
</map:aggregate>
A RegexpSelector and a MatchSelector might be acceptable because they
would not affect other classes.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by Mark Lundquist <lu...@gmail.com>.
On Mar 17, 2008, at 5:17 PM, Mark Lundquist wrote:
> You might find this interesting:
>
> http://thread.gmane.org/gmane.text.xml.cocoon.devel/68380/focus=68408
whoops, I meant just this:
http://thread.gmane.org/gmane.text.xml.cocoon.devel/68380
:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by Mark Lundquist <ml...@wrinkledog.com>.
Hi Rainer,
On Feb 21, 2008, at 5:49 AM, Rainer Pruy wrote:
> Hi,
> probably a question with a simple answer.
> However, I just failed up to now in getting at it.....
>
> wildcard *matcher* is one of the most used components with cocoon,
> I'd reckon.
>
> But what to do, when one needs to handle X/c/** and X/** (excluding
> X/c/**) different?
> (At least if the contained components are not "final" (serialize,
> read))
>
> ("X" is an arbitrary path, not having any single path component "c";
> while "c" is a simple path component (no "/"))
>
> Using combinations of wildcard macher and simple selector does work,
> but is quite verbose.
> A "not c" pattern is not generally available (decomposing c into
> positive and negative set patterns
> might work, but will be even more writing for c's that include
> several characters).
>
> Any selector I did miss?
A while back, I made a proposal for dealing with this and other
closely related issues. I noticed that Cocoon was missing some
matchers and selectors that would be really nice to have, and when I
looked at maybe contributing some of the missing ones, I realized that
the whole matching and selecting business in Cocoon is kind of brain-
damaged. You might find this interesting:
http://thread.gmane.org/gmane.text.xml.cocoon.devel/68380/focus=68408
Note, I said "interesting", not "helpful"... sorry :-)
That proposal didn't go anywhere because I started medical school and
didn't have any time to work on implementing it. But, summer is
coming, so who knows?
cheers,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by Derek Hohls <DH...@csir.co.za>.
Rainer
Ok; it was just a suggestion. I won't debate "easy" as that is a
completely
subjective term that no one will agree on :) but I am curious though as
to
what you think would be a "cleaner" solution that a regexp; which are
designed to be powerful and flexible? Perhaps if you have a better
option
you could suggest it to the developers.
Derek
>>> On 2008/02/21 at 04:22, in message <47...@acrys.com>,
Rainer Pruy <Ra...@Acrys.COM> wrote:
Derek,
thanks for your answer.
Yes, I'm pretty aware of the possibility of writing my own selector.
A solution based on existing "regexp-header" seemed not really to be
easier or cleaner than what I'm using up to now.
I just am curious whether I did "miss the obvious".
Rainer
Derek Hohls schrieb:
> Rainer
>
> I am sure you will get a better answer than this :)
> but, off the top of my head, could you not implement
> a selector, inside your general case matcher, which could
> make use of regular expressions to handle any degree
> of complexity - see:
>
http://cocoon.apache.org/2.1/userdocs/regular-expression-header-selector.html
>
> Derek
>
> PS I agree that its more "verbose" but then terseness was
> never a design goal of XML !!
>
>>>> On 2008/02/21 at 03:49, in message <47...@acrys.com>,
Rainer Pruy <Ra...@Acrys.COM> wrote:
> Hi,
> probably a question with a simple answer.
> However, I just failed up to now in getting at it.....
>
> wildcard *matcher* is one of the most used components with cocoon,
I'd reckon.
>
> But what to do, when one needs to handle X/c/** and X/** (excluding
X/c/**) different?
> (At least if the contained components are not "final" (serialize,
read))
>
> ("X" is an arbitrary path, not having any single path component "c";
> while "c" is a simple path component (no "/"))
>
> Using combinations of wildcard macher and simple selector does work,
but is quite verbose.
> A "not c" pattern is not generally available (decomposing c into
positive and negative set patterns
> might work, but will be even more writing for c's that include
several characters).
>
> Any selector I did miss?
>
> Regards,
> Rainer
>
--
Rainer Pruy
Geschäftsführer
Acrys Consult GmbH & Co. KG
Untermainkai 29-30, D-60329 Frankfurt
Tel: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com ( http://www.acrys.com/ ) - Email:
office@acrys.com
Handelsregister: Frankfurt am Main, HRA 31151
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by Rainer Pruy <Ra...@Acrys.COM>.
Derek,
thanks for your answer.
Yes, I'm pretty aware of the possibility of writing my own selector.
A solution based on existing "regexp-header" seemed not really to be easier or cleaner than what I'm using up to now.
I just am curious whether I did "miss the obvious".
Rainer
Derek Hohls schrieb:
> Rainer
>
> I am sure you will get a better answer than this :)
> but, off the top of my head, could you not implement
> a selector, inside your general case matcher, which could
> make use of regular expressions to handle any degree
> of complexity - see:
> http://cocoon.apache.org/2.1/userdocs/regular-expression-header-selector.html
>
> Derek
>
> PS I agree that its more "verbose" but then terseness was
> never a design goal of XML !!
>
>>>> On 2008/02/21 at 03:49, in message <47...@acrys.com>, Rainer Pruy <Ra...@Acrys.COM> wrote:
> Hi,
> probably a question with a simple answer.
> However, I just failed up to now in getting at it.....
>
> wildcard *matcher* is one of the most used components with cocoon, I'd reckon.
>
> But what to do, when one needs to handle X/c/** and X/** (excluding X/c/**) different?
> (At least if the contained components are not "final" (serialize, read))
>
> ("X" is an arbitrary path, not having any single path component "c";
> while "c" is a simple path component (no "/"))
>
> Using combinations of wildcard macher and simple selector does work, but is quite verbose.
> A "not c" pattern is not generally available (decomposing c into positive and negative set patterns
> might work, but will be even more writing for c's that include several characters).
>
> Any selector I did miss?
>
> Regards,
> Rainer
>
--
Rainer Pruy
Geschäftsführer
Acrys Consult GmbH & Co. KG
Untermainkai 29-30, D-60329 Frankfurt
Tel: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com - Email: office@acrys.com
Handelsregister: Frankfurt am Main, HRA 31151
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by Derek Hohls <DH...@csir.co.za>.
Rainer
I am sure you will get a better answer than this :)
but, off the top of my head, could you not implement
a selector, inside your general case matcher, which could
make use of regular expressions to handle any degree
of complexity - see:
http://cocoon.apache.org/2.1/userdocs/regular-expression-header-selector.html
Derek
PS I agree that its more "verbose" but then terseness was
never a design goal of XML !!
>>> On 2008/02/21 at 03:49, in message <47...@acrys.com>, Rainer Pruy <Ra...@Acrys.COM> wrote:
Hi,
probably a question with a simple answer.
However, I just failed up to now in getting at it.....
wildcard *matcher* is one of the most used components with cocoon, I'd reckon.
But what to do, when one needs to handle X/c/** and X/** (excluding X/c/**) different?
(At least if the contained components are not "final" (serialize, read))
("X" is an arbitrary path, not having any single path component "c";
while "c" is a simple path component (no "/"))
Using combinations of wildcard macher and simple selector does work, but is quite verbose.
A "not c" pattern is not generally available (decomposing c into positive and negative set patterns
might work, but will be even more writing for c's that include several characters).
Any selector I did miss?
Regards,
Rainer
--
Rainer Pruy
Managing Director
Acrys Consult GmbH & Co. KG
Untermainkai 29-30, D-60329 Frankfurt, Germany
Phone: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com ( http://www.acrys.com/ ) - Email: office@acrys.com
Registered: Frankfurt am Main, HRA 31151
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by Rainer Pruy <Ra...@Acrys.COM>.
Joerg Heinicke schrieb:
>
> Both possible pipeline "paths" would be correct. Only problem is to find
> the mutually exclusive patterns as you run into the second match
> otherwise and have 2 generators. And I think here is where Rainer had
> his problems, there is no "not" to just inverse the first condition with
> the wildcard matcher (while the selector just has an otherwise). Rainer
> might confirm my understanding :-)
That is it exactly.
Most suggestions depend in the end on having mutually exclusive patterns.
>
>> Solprovider suggested to use resources but I would go with several
>> different internal pipelines that
>> would work as generators.
>
> Resources are indeed a kind of work around. You don't need mutually
> exclusive patterns anymore since inside each matcher you have a complete
> pipeline.
>
> I prefer your internal pipelines approach though since it is much more
> flexible and closer to the original idea. It also has advantages in
> terms of caching since internal pipelines are cached separately.
>
> Joerg
I also prefer using pipelines over resources.
With 2.1.x I made heavy use of resources but this quickly turns out quite complex, if you enter using cascaded resources and passing
along numerous parameters.
However, I am a bit reluctant adding another level of pipelines just for implementing a 2-n valued alternative.
This quickly turns out (unnecessarily) complex either.
As I am not aware of a simple component providing such functionality on urls, I asked here.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.03.2008 20:54, Grzegorz Kossakowski wrote:
>> - the condition "does not contain C" is not stated easily in terms of wildcard
>> (just consider: what is the "not" of pattern "**/special treatment_area/**"
>> and keep in mind, that I do not have control over the undelying namespace
>> as I then could move the normal processing to "**/normal/**" e.g.)
>
> I'm still not sure if I get your requirements correctly but I think that you could use just several
> matchers to achieve "not" pattern functionality.
>
> I presume you need something like that:
> if (here some specific pattern) { .... } else { ... }
>
> then you can use:
> <map:match pattern="some specific pattern">
> ...
> </map:match>
>
> <map:match pattern="some general pattern like **">
> ...
> </map:match>
>
> The second one will match only if the first one doesn't.
It depends how you want to set up the pipeline and - depending on this -
if the match pattern have to be mutually exclusive. In theory the
following is possible and probably most straight-forward:
<map:match pattern="mutuallyExclusivePattern1">
<map:generate src="src1"/>
</map:match>
<map:match pattern="mutuallyExclusivePattern2">
<map:generate src="src2"/>
</map:match>
<map:transform/>
<map:serialize/>
Both possible pipeline "paths" would be correct. Only problem is to find
the mutually exclusive patterns as you run into the second match
otherwise and have 2 generators. And I think here is where Rainer had
his problems, there is no "not" to just inverse the first condition with
the wildcard matcher (while the selector just has an otherwise). Rainer
might confirm my understanding :-)
> Solprovider suggested to use resources but I would go with several different internal pipelines that
> would work as generators.
Resources are indeed a kind of work around. You don't need mutually
exclusive patterns anymore since inside each matcher you have a complete
pipeline.
I prefer your internal pipelines approach though since it is much more
flexible and closer to the original idea. It also has advantages in
terms of caching since internal pipelines are cached separately.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Rainer Pruy pisze:
> Thanks,
> yes, I am aware of nesting.
>
> To get closer to my question, just assume (may not have been stated clearly by me with initial post):
>
> - the condition "does not contain C" is not stated easily in terms of wildcard
> (just consider: what is the "not" of pattern "**/special treatment_area/**"
> and keep in mind, that I do not have control over the undelying namespace
> as I then could move the normal processing to "**/normal/**" e.g.)
I'm still not sure if I get your requirements correctly but I think that you could use just several
matchers to achieve "not" pattern functionality.
I presume you need something like that:
if (here some specific pattern) { .... } else { ... }
then you can use:
<map:match pattern="some specific pattern">
...
</map:match>
<map:match pattern="some general pattern like **">
...
</map:match>
The second one will match only if the first one doesn't.
> - the condition does only affect generators (in my case usually aggregators),
> the rest of the pipeline will be the same
> Thus, using the "return" character of "serialize" would also require multiplying the same pipeline
Solprovider suggested to use resources but I would go with several different internal pipelines that
would work as generators. I mean you create one general pipeline containing set of components common
to all flows and call specialized pipelines:
<map:match pattern="/*/**">
<map:generate src="cocoon:/specialized/{1}/{2}"/> <!-- if you use Cocoon 2.2 I suggest to use
servlet source instead -->
[here goes the rest of the pipeline]
</map:match>
<map:match pattern="specialized/A/**">
<map:generate .../>
<map:serialize type="xml"/>
</map:match>
<map:match pattern="specialized/B/**">
<map:generate .../>
<map:serialize type="xml"/>
</map:match>
<map:match pattern="specialized/*/**">
<!-- called only if above does not match -->
<map:generate .../>
<map:serialize type="xml"/>
</map:match>
I hope that fits your use-case.
Best regards,
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by so...@apache.org.
Avoiding duplication of code in XMAPs is handled by "resources":
<map:resources>
<map:resource name="finish">
<map:transform src="transform1.xsl"/>
<map:transform src="transform2.xsl"/>
<map:transform type="i18n">
<map:parameter name="locale" value="{request:locale}"/>
</map:transform>
<map:serialize type="xml"/>
</map:resource>
</map:resources>
...
<map:match pattern="**">
<map:match pattern="**/special treatment_area/**">
<!-- Pattern contains "/special treatment_area/" -->
<map:generate src="Special.xml"/>
<map:call resource="finish"/>
</map:match>
<!-- Pattern does not contain "/special treatment_area/" -->
<map:generate src="NotSpecial.xml"/>
<map:call resource="finish"/>
</map:match>
Note that resources can contain any portion of a pipeline and do not
require any specific components. A resource could be just a
Generator, just a Serializer, a few Transformers, or any combination
as long as every pipeline that calls the resources has one and only
one Generator/Aggregator and at least one Serializer. Multiple
Serializers are allowed; the first Serializer encountered is the
"return" command ending processing. Every <map:call> statement is
replaced by the code in the named resource.
We discuss using variables with resources in the advanced class.
solprovider
On 3/5/08, Rainer Pruy <Ra...@acrys.com> wrote:
> Thanks,
> yes, I am aware of nesting.
>
> To get closer to my question, just assume (may not have been stated clearly by me with initial post):
>
> - the condition "does not contain C" is not stated easily in terms of wildcard
> (just consider: what is the "not" of pattern "**/special treatment_area/**"
> and keep in mind, that I do not have control over the undelying namespace
> as I then could move the normal processing to "**/normal/**" e.g.)
>
> - the condition does only affect generators (in my case usually aggregators),
> the rest of the pipeline will be the same
> Thus, using the "return" character of "serialize" would also require multiplying the same pipeline
>
> Rainer
>
> solprovider@apache.org schrieb:
>
> > Are you aware that pipelines can be nested?
> > http://solprovider.com/lenya/nesting
> >
> > <map:match pattern="**">
> > <map:match pattern="**/C/**">
> > <!-- Pattern contains "/C/" -->
> > <map:generate src="FoundC.xml"/>
> > <map:serialize type="xml"/>
> > </map:match>
> > <!-- Pattern does not contain "C" -->
> > <map:generate src="NoCFound.xml"/>
> > <map:serialize type="xml"/>
> > </map:match>
> >
> > Each piece of code must start with an Generator/Aggregator and end
> > with a Serializer (or call a Reader or Redirector.) Think of
> > <map:serialize> as a return statement.
> >
> > Is this the information you need? Or did I miss the problem?
> >
> > solprovider
> >
> > On Thu, Feb 21, 2008 at 8:49 AM, Rainer Pruy <Ra...@acrys.com> wrote:
> >> But what to do, when one needs to handle X/c/** and X/** (excluding X/c/**) different?
> >> (At least if the contained components are not "final" (serialize, read))
> >>
> >> ("X" is an arbitrary path, not having any single path component "c";
> >> while "c" is a simple path component (no "/"))
> >>
> >> Using combinations of wildcard macher and simple selector does work, but is quite verbose.
> >> A "not c" pattern is not generally available (decomposing c into positive and negative set patterns
> >> might work, but will be even more writing for c's that include several characters).
> >>
> >> Any selector I did miss?
> >>
> >> Regards,
> >> Rainer Pruy
> Rainer Pruy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by Rainer Pruy <Ra...@Acrys.COM>.
Thanks,
yes, I am aware of nesting.
To get closer to my question, just assume (may not have been stated clearly by me with initial post):
- the condition "does not contain C" is not stated easily in terms of wildcard
(just consider: what is the "not" of pattern "**/special treatment_area/**"
and keep in mind, that I do not have control over the undelying namespace
as I then could move the normal processing to "**/normal/**" e.g.)
- the condition does only affect generators (in my case usually aggregators),
the rest of the pipeline will be the same
Thus, using the "return" character of "serialize" would also require multiplying the same pipeline
Rainer
solprovider@apache.org schrieb:
> Are you aware that pipelines can be nested?
> http://solprovider.com/lenya/nesting
>
> <map:match pattern="**">
> <map:match pattern="**/C/**">
> <!-- Pattern contains "/C/" -->
> <map:generate src="FoundC.xml"/>
> <map:serialize type="xml"/>
> </map:match>
> <!-- Pattern does not contain "C" -->
> <map:generate src="NoCFound.xml"/>
> <map:serialize type="xml"/>
> </map:match>
>
> Each piece of code must start with an Generator/Aggregator and end
> with a Serializer (or call a Reader or Redirector.) Think of
> <map:serialize> as a return statement.
>
> Is this the information you need? Or did I miss the problem?
>
> solprovider
>
> On Thu, Feb 21, 2008 at 8:49 AM, Rainer Pruy <Ra...@acrys.com> wrote:
>> But what to do, when one needs to handle X/c/** and X/** (excluding X/c/**) different?
>> (At least if the contained components are not "final" (serialize, read))
>>
>> ("X" is an arbitrary path, not having any single path component "c";
>> while "c" is a simple path component (no "/"))
>>
>> Using combinations of wildcard macher and simple selector does work, but is quite verbose.
>> A "not c" pattern is not generally available (decomposing c into positive and negative set patterns
>> might work, but will be even more writing for c's that include several characters).
>>
>> Any selector I did miss?
>>
>> Regards,
>> Rainer Pruy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Rainer Pruy
Geschäftsführer
Acrys Consult GmbH & Co. KG
Untermainkai 29-30, D-60329 Frankfurt
Tel: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com - Email: office@acrys.com
Handelsregister: Frankfurt am Main, HRA 31151
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Is there an "url wildcard" selector (equivalent)
Posted by so...@apache.org.
Are you aware that pipelines can be nested?
http://solprovider.com/lenya/nesting
<map:match pattern="**">
<map:match pattern="**/C/**">
<!-- Pattern contains "/C/" -->
<map:generate src="FoundC.xml"/>
<map:serialize type="xml"/>
</map:match>
<!-- Pattern does not contain "C" -->
<map:generate src="NoCFound.xml"/>
<map:serialize type="xml"/>
</map:match>
Each piece of code must start with an Generator/Aggregator and end
with a Serializer (or call a Reader or Redirector.) Think of
<map:serialize> as a return statement.
Is this the information you need? Or did I miss the problem?
solprovider
On Thu, Feb 21, 2008 at 8:49 AM, Rainer Pruy <Ra...@acrys.com> wrote:
> But what to do, when one needs to handle X/c/** and X/** (excluding X/c/**) different?
> (At least if the contained components are not "final" (serialize, read))
>
> ("X" is an arbitrary path, not having any single path component "c";
> while "c" is a simple path component (no "/"))
>
> Using combinations of wildcard macher and simple selector does work, but is quite verbose.
> A "not c" pattern is not generally available (decomposing c into positive and negative set patterns
> might work, but will be even more writing for c's that include several characters).
>
> Any selector I did miss?
>
> Regards,
> Rainer Pruy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org