cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David <cocoon-n...@max-imp.com>
Subject Re: negate match
Date Sat, 10 Sep 2005 00:18:20 GMT
Lars Huttar wrote:
> David wrote:
> 
>> Tony Collen wrote:
>>
>>> Tony Collen wrote:
>>>
>>>> Hmm, it actually might not be all that easy.  The RegexpURIMatcher 
>>>> uses the org.apache.regexp package.
>>>>
>>>> Details about the syntax are at:
>>>>
>>>> http://jakarta.apache.org/regexp/apidocs/org/apache/regexp/RE.html
>>>>
>>>> and it seems like you can do negation, but only with character 
>>>> classes (Unless I'm missing something painfully obvious)
>>>>
>>>> I guess the brute force ugly way would be to subclass 
>>>> AbstractRegexpMatcher to return true if the RE *doesn't* match, or 
>>>> allow the matcher to take a parameter to tell it to use inverse 
>>>> logic for determining a match.
>>>
>>>
>>>
>>>
>>>
>>> I take that back. This works:
>>>
>>>     <map:match type="regexp" pattern="^bob$">
>>>           <map:generate src="bob.xml"/>
>>>           <map:serialize type="xml"/>
>>>     </map:match>
>>>
>>>     <map:match type="regexp" pattern="[^b][^o][^b]">
>>>         <map:generate src="notbob.xml"/>
>>>         <map:serialize type="xml"/>
>>>     </map:match>
>>>
>>> HTH,
>>>
>>> Tony
>>
>>
>>
>>
>> The problem with the above is it will only match 3 letter long urls (I 
>> am pretty sure). Eg. 'ab' would not be matched by the second regex.
> 
> 
> It will not even match all 3-letter URLs other than 'bob'. For example, 
> it will not match 'ben' because its first letter is 'b'.
> 
> 
> However, you can get the right behavior by doing this:
> 
>    <map:match pattern="bob">
>       <!-- return 404 or whatever you want to do for 'bob' -->
>       <map:serialize ... />
>    </map:match>
> 
>    <map:match pattern="**">
>       <!-- here's where you match everything except 'bob' -->
>    </map:match>
> 
> Since the first pattern that matches a URL is the one that fires, the 
> second pattern will match everything except whatever is matched by 
> previous patterns... So the second pattern will match everything except 
> 'bob'.
> Does that fit your requirements?
> 
> Lars

Good point on the 'ben' thing.

Upayavira responded with a very similar response about the matches.

I had already thought of doing it that way and had to go this direction 
even though I do not feel it is clean solution.  Let me give a more 
detailed example of what I really need this for.

In Lenya when you publish a site it keeps a cached version of pages. 
When you access the live site it checks to see if a cache copy exists to 
serve. Pseudo explanation:
--------------------------
if ( live site request and cache copy of requested page exists ) {
     serve cache copy
}
// No cache. Generate.
a lot of code right here that does the page generation
--------------------------

Now I wanted to change it so certain pages are never served from the 
cache because they are dynamic. If I go the route you recommended I 
would have to write:
--------------------------
if ( live site request and one of the pages that we do not want to serve 
from cache) {
     // No cache. Generate.
     a lot of code right here that does the page generation
}
if ( live site request and cache copy of requested page exists ) {
     serve cache copy
}
// No cache. Generate.
a lot of code right here that does the page generation
--------------------------

Now you see I had to copy the 'a lot of code right here that does the 
page generation' into the if i put before the cache check. We obviously 
do not want to do this -- we all now the horrors of copying and pasting.

Now I seem to have three solutions:
1. Create an if that says if NOT these urls and put it around the cache 
check.
2. Go with the above example and put the shared code into resource.
3. Mount a xmap file for the shared code.

Number 2 and number 3 are ABOUT the same in this instance but I really 
do not like either because...
  - people are lazy and WILL copy in paste when these situations pop up.
  - you need to jump around the document to read the xmap file that is 
already hard to read.
  - it simply ... feels messy.

#1 only seems possible when you use a regular expression (only 
'theoretically' I guess since we haven't been able to get it to work). 
Even if it is possible it doesn't make sense that we are limited to the 
regular expression matcher when we need to negate a match.

These same type of problems exist when we need an 'or'.

I guess.. what I am saying is I wish more complex matches were possible 
in xmap files. We should be allowed to do 'nots' and 'ors'.

I also wish we could do something about the '{../../../../1}' syntax 
since it can easily lead to errors when you add something such as a 
match that increases elements depth -- but this is something for a later 
discussion. (........ fine, one last thing about this. To solve this I 
think matchers should let us name 1,2,3,etc. so you can use a name 
reference instead of numbers with periods.)

Please let me know what others think. I really love Cocoon but do feel 
there are some very basic issues with parts of it that need to be addressed.

If adding the ability to 'negate' matches and do 'ors' does not make 
sense please explain why so I can better understand the thinking behind 
xmaps.

Thanks,
David



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message