cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Burton" <ross.bur...@mail.com>
Subject Re: [Cocoon 2] Regex matchers :-)
Date Wed, 10 May 2000 17:30:00 GMT
> > Well, I've bitten the bullet and decided to learn regex's properly.  And
> > what better way then writing mod_rewrite for Cocoon 2!  :-)
>
> <horribly-face-devastated-by-fear belongs-to="stefano">
> AAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!
> </horribly-face-devastated-by-fear>

:-)

I knew you'd like this.  I'm not suggesting that this should be part of
Cocoon 2, it's just that somebody, somewhere, might need the power.  My
other excuse is that this is a good test of Cocoon 2 sittemap and regex
programming skills...

> > * matching of URLs and rewriting based on backreferences (completed but
not
> > throughly tested)
> Let me ask you: why?

Because.  ;-)

> My humble opinion is: if you need full regexp power to map your
> resources to your URI space, you have a problem in your URI space.
> I'd be happy to be proven wrong on this, but so far, nobody proposed me
> a URI space that is not addressable with *,?,** wildcards.
> On the other hand, I agree that no matter how hard I try to enforce my
> vision, having this matching syntax fixed could create forking
> frictions....
> So, I'm ok to provide pluggable hooks for syntax matching engines, but
> about shipping regexp matching engines with Cocoon, well, that's another
> story.

I've no problems with not seeing this code ever enter the Cocoon 2 CVS, it's
just that pluggable matching engines seem like a good idea, even if it
requires a restart of Cocoon to take effect.

> > * inserting data in the parameters for this request (?)
>
> no way, this is mod_rewrite and Cocoon doesn't need this kind of hacking
> on the request since it has a full blown architecture to deal with this.
> The sitemap does mapping, nothing else.

The question mark was to indicate that this is a "not sure" item - I'll
forget it.

> > * client-side redirects, for "out-dated" URLs.  This should really be
used
> > as a compatibility phase as Cocoon 2 based sites go public, as a public
URL
> > space should not change if it is well designed.
> Can you elaborate more on this?

Take the (hopefully soon) common scenario of a traditional HTML web site
which has a rather horrible structure to it.  They kick out the old server
and replace all of the content with XML in Cocoon 2 and a structured
extendable URI space.  However, many people have links into the old URI
space which need to be maintained.  So Cocoon 2 should accept an old URI,
and send a redirect to the client, so that they go to the correct new page
and are informed of the new URL (the location changes).  I think that this
needs to be addressed in the sitemap somehow, maybe with a <redirect> block
along with the <process> blocks.

Hmm....

Regards,
Ross Burton



Mime
View raw message