cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [Cocoon 2] Regex matchers :-)
Date Thu, 11 May 2000 13:03:01 GMT
Ross Burton wrote:
> > > 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">
> > </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.  ;-)

you geek :)
> > 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.

ok, great, just making sure...
> > > * 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
> > > 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....

Hmmmm, I see your point...

Anyone else about this?

I think you touched a very important point I tried not to touch before:
site migration. While the goal is to make the sitemap simple and
effective, you are right that normally people have to migrate one site
into another, possibly doing URI-space rearchitecting without breaking
usage and creating floods of broken links.

I'm wide open to suggestions on this.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message