Re: negate match
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
Re: negate match
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:calls 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: negate match
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: negate match
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
Re: negate match
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/ * [EMAIL PROTECTED] * +358 44 561 0270 *
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: negate match
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: negate match
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: negate match
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: negate match
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: negate match
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
