cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
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">
> > 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...

ok
 
> > > * 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.

good
 
> > > * 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....

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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message