cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: Is there an "url wildcard" selector (equivalent)
Date Thu, 06 Mar 2008 01:33:03 GMT
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


Mime
View raw message