You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by David <co...@max-imp.com> on 2005/09/08 22:36:41 UTC
negate match
Is there a way to negate a match in cocoon?
For example how do I do something to all urls that do NOT contain the
word 'bob'?
Also what is the recommended way of doing an 'or' in an xmap file?
It doesn't seem possible which causes people to copy and paste code all
around -- which is obviously really bad to be doing.
Thanks,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: negate match
Posted by Upayavira <uv...@odoko.co.uk>.
I tend to achieve this with:
<map:match pattern="bob">
...
</map:match>
<map:match pattern="*"> <!-- everything else -->
</map:match>
Don't know if that will work for you.
Upayavira
David wrote:
> I have been but it isn't working. Do you konw what the correct negation
> operator is?
>
> I know this works in PHP: ^((?!bob).)*$
> and I read that this should work in Java: ((?!bob).)*
> but it does not work in xmap's regexp matcher.
>
> An example would be great.
> Eg.
> "!bob"
>
> Thanks,
> David
>
> Tony Collen wrote:
>
>> David wrote:
>>
>>> Is there a way to negate a match in cocoon?
>>>
>>> For example how do I do something to all urls that do NOT contain the
>>> word 'bob'?
>>>
>>> Also what is the recommended way of doing an 'or' in an xmap file?
>>> It doesn't seem possible which causes people to copy and paste code
>>> all around -- which is obviously really bad to be doing.
>>
>>
>>
>> Try the regexp matcher, with the correct regexp with the negation
>> operator.
>>
>> Tony
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: negate match
Posted by Lars Huttar <la...@sil.org>.
Upayavira wrote:
> Michael Schlotfeldt wrote:
>
>> I completely agree with David. Sitemaps are to primitive at this
>> point. The addition of "and" and "or" to matchers would be a big step
>> forward.
>
>
> AND:
> <map:match pattern="x">
> <map:match pattern="y">
> ...
> </map:match>
> </map:match>
>
> OR:
> <map:match pattern="x">
> ..
> </map:match>
> <map:match pattern="y">
> ...
> </map:match>
>
> Isn't that enough for and and or?
For AND, it works, although it's not as readable and maintainable as an
explicit AND would be. Imagine Java not having && and ||, so you had to say
if (foo) {
if (bar) {
instead of
if (foo && bar) {
For OR, the point is that with this method you have to duplicate code.
Granted, you could probably minimize code duplication with a couple of
<map:call>s to a common code block.
But ideally an explicit OR without having to create a separate thing to
call would be nicer.
But how would it be designed? In order to have multiple match patterns,
you'd have either put repeating pattern elements inside the <map:match>,
or design the and/or construct into the pattern syntax. Certain brands
of regexp syntax do have an OR construct. Don't think I've heard of an
AND though.
This would also limit you to making all the operands of your ANDs and
ORs be of the same kind -- a match pattern or regexp.
A cleaner construct, maybe something like selectors, would let specify
multiple conditions of different kinds for entering a block of code and
a full grammar for expressing conditions... e.g.
<map:condition-block>
<map:and>
<map:match pattern="..."/>
<map:or>
<map:not>
<map:match type="regexp" pattern="...."/>
</map:not> </map:or> </map:and>
<!-- if the above condition is met, execute the following code -->
...
</map:condition-block>
But XML elements are a pretty long-winded way of describing
expressions... that's why XSLT uses XPath, no doubt.
Besides, we all know Cocoon is supposed to let you create web
applications "without programming" (wink wink).
Lars
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: negate match
Posted by Upayavira <uv...@odoko.co.uk>.
Michael Schlotfeldt wrote:
> I completely agree with David. Sitemaps are to primitive at this point.
> The addition of "and" and "or" to matchers would be a big step forward.
AND:
<map:match pattern="x">
<map:match pattern="y">
...
</map:match>
</map:match>
OR:
<map:match pattern="x">
..
</map:match>
<map:match pattern="y">
...
</map:match>
Isn't that enough for and and or?
Upayavira
> David wrote:
>
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: negate match
Posted by Michael Schlotfeldt <mj...@max-imp.com>.
I completely agree with David. Sitemaps are to primitive at this point.
The addition of "and" and "or" to matchers would be a big step forward.
I think he also has a good point about variables. The current setup does
not follow the same theory of many other parts of Cocoon. Example,
components use "named" paramaters. This logic should be continued to
matchers. Order and depth should not matter.
-Michael
David wrote:
> 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
Re: negate match
Posted by David <co...@max-imp.com>.
Joose Vettenranta wrote:
>> 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
>> --------------------------
>
>
> It's not an option to use cocoon cache?
>
> how about pseudo like this:
>
> match ** {
> action (isPageCached) { serialize from cache }
>
> generate {
> generate...transform....
> match cached / or an action to see if page is cacheable {
> serialize to cache and browser
> }
> serialize to browser
> }
> }
>
> like this, no need to keep same code twice..
>
> Also resources are nice things to make sitemap things easier...
>
> - Joose
>
> --
> "Always remember that you are unique, just like everyone else!"
> * http://iki.fi/joose/ * joose@iki.fi * +358 44 561 0270 *
I could possibly use Cocoon's cache but that is beside the point. This
solution simply addresses this specific example and not the actual issue.
As I admitted there are ways to accomplish what I needed to do but they
take more work than they should. Having the ability to negate matches
and do ors would increase productivity by simplifying solutions and
making xmap files to be easier to read. I am sure we would all agree
that Cocoon should help speed up creation -- not slow it down.
I do like your idea of checking to see if the page should be cached
instead of going my route of seeing if the cache should be used. Your
way does seem much better but nevertheless it does seem I still need to
be able to negate a match or write a customer action.
Thanks,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: negate match
Posted by Joose Vettenranta <jo...@iki.fi>.
> 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
> --------------------------
It's not an option to use cocoon cache?
how about pseudo like this:
match ** {
action (isPageCached) { serialize from cache }
generate {
generate...transform....
match cached / or an action to see if page is cacheable {
serialize to cache and browser
}
serialize to browser
}
}
like this, no need to keep same code twice..
Also resources are nice things to make sitemap things easier...
- Joose
--
"Always remember that you are unique, just like everyone else!"
* http://iki.fi/joose/ * joose@iki.fi * +358 44 561 0270 *
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: negate match
Posted by David <co...@max-imp.com>.
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
Re: negate match
Posted by Lars Huttar <la...@sil.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: negate match
Posted by David <co...@max-imp.com>.
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.
The regular expression I need to use is also much more complex then 'bob'
Knowing what regular expression library is a good thing to know. Thanks.
That should help me figure it out.
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: negate match
Posted by Tony Collen <co...@umn.edu>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: negate match
Posted by Tony Collen <co...@umn.edu>.
David wrote:
> I have been but it isn't working. Do you konw what the correct negation
> operator is?
>
> I know this works in PHP: ^((?!bob).)*$
> and I read that this should work in Java: ((?!bob).)*
> but it does not work in xmap's regexp matcher.
>
> An example would be great.
> Eg.
> "!bob"
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.
Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: negate match
Posted by David <co...@max-imp.com>.
I have been but it isn't working. Do you konw what the correct negation
operator is?
I know this works in PHP: ^((?!bob).)*$
and I read that this should work in Java: ((?!bob).)*
but it does not work in xmap's regexp matcher.
An example would be great.
Eg.
"!bob"
Thanks,
David
Tony Collen wrote:
> David wrote:
>
>> Is there a way to negate a match in cocoon?
>>
>> For example how do I do something to all urls that do NOT contain the
>> word 'bob'?
>>
>> Also what is the recommended way of doing an 'or' in an xmap file?
>> It doesn't seem possible which causes people to copy and paste code
>> all around -- which is obviously really bad to be doing.
>
>
> Try the regexp matcher, with the correct regexp with the negation operator.
>
> Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: negate match
Posted by Tony Collen <co...@umn.edu>.
David wrote:
> Is there a way to negate a match in cocoon?
>
> For example how do I do something to all urls that do NOT contain the
> word 'bob'?
>
> Also what is the recommended way of doing an 'or' in an xmap file?
> It doesn't seem possible which causes people to copy and paste code all
> around -- which is obviously really bad to be doing.
Try the regexp matcher, with the correct regexp with the negation operator.
Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org