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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
