incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murray Altheim <>
Subject Re: REST-ful URLs [Was: url rewriting supported?]
Date Tue, 08 Jul 2008 08:28:33 GMT
Janne Jalkanen wrote:
>>> This presents more of a challenge. We need some way of transforming 
>>> the inbound URL into a normal request -- with normal parameters -- so 
>>> that Stripes can locate the right bean, [etc.]
>>> Originally I was thinking we'd need to write our own filter to do 
>>> this, or use URLRewrite. It turns out some clever Stripes devs got 
>>> there first. They call this the "clean URL" feature. It was initially 
>>> a user contribution, but the Gregg and Tim liked it so much they put 
>>> it into the trunk.
>>> I have been watching the 1.5 builds, but TOTALLY forgot about this. 
>>> Needless to day, it completely solves the problem, and it makes my 
>>> previous comments about needing an external filter totally obsolete. 
>>> Assuming you buy into the Stripes Way, the URL scheme you describe 
>>> can be completely accommodated.
> BTW, I think this is evil.  It gives you a fixed URI scheme, and sooner 
> or later you end up with URLs that look like /foo/-/-/-/a/-/-/-/c/-/-/-/
> You see them all around these days.

I don't follow. How? If we maintain a flat wiki namespace, are using
wiki page names as we do now as oids, have one predicate and everything
else is passed as query arguments we have a schema that looks like:

What's wrong with that?

>>> "Clean URLs support both prefix mapping (/action/foo/{bar}) and 
>>> extension mapping (/foo/{bar}.action). Any number of parameters 
>>> and/or literals may be omitted from the end of a request URL."
> The problem is that you can't do it from the middle of the request.
>> Almost all of our present services are in need of an architectural
>> overview, and what we're trying to do is (sorry to the use the word
>> again, but) rationalize the URL schema.
> We can't without breaking the URLs of all the existing websites.  *And* 
> some of them are using the ShortViewURLConstructor and some of them are 
> using the DefaultURLConstructor.  I think this is a design parameter 
> which we simply cannot afford to break.

That's not an issue since I wouldn't propose to use this with existing
websites. No existing website *can* change its URL schema constructor
without breaking all the bookmarks of all its current users. Even if
I *could* get the ShortURLConstructor to work with the CeryleWiki (and
I've not been able to since the directory level from the base URL won't
permit it, or some such thing), I have to deal with the fact that anyone
who has a bookmarked page or uses any URL reference to a page on my
site will get a 404 if I change my scheme. In my case I'll probably
just change it, but this is a non-issue for most *existing* sites -- I'm
only thinking of this for new sites.

> (And no, mod_rewrite is not an answer.)
>> What I'm thinking is that Janne doesn't sound all that enthusiastic
>> about this so it might have to fit into the application as another
> The Stripes stuff is great - IF you are writing a new app.  If you're 
> trying to retrofit it to the existing schema, I would very strongly 
> hesitate to just use it because it's great and we have it - that'll end 
> up in a translation layer in front of the Beans which just muddy the 
> waters so that we can use Annotations.  It'll be just like the Command 
> superstructure, but in another form ;-)

I am writing a new app.

> Note that this CleanURI feature is new in Stripes 1.5 (which isn't even 
> out yet in a stable form), and there have been tons of successful 
> applications made in Stripes 1.4 and earlier.  I don't see it as a 
> strong requirement to enforce this architecture.

I'm not suggesting it is a strong requirement of yours, only that if
I'm going to use JSPWiki and get it to fit into our larger service
framework I'm going to need something like what Andrew has suggested
can be provided via Stripes, and it'd be great if that URL schema was
also the one used by the wiki generally. A very good fit, really.

And if it were modular (I'm here telegraphing an email from you I
just received) it might be possible to fit this onto a 2.8 implementa-
tion by hooking it into the wiki in the same way as the existing URL
constructors are handled. When we get to 3.0 we may have a nicer way
of doing it but if well designed we wouldn't have to replace anything,
just change the means of attachment/message passing.


Murray Altheim <murray07 at>                           ===  = =                                     = =  ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =

       Boundless wind and moon - the eye within eyes,
       Inexhaustible heaven and earth - the light beyond light,
       The willow dark, the flower bright - ten thousand houses,
       Knock at any door - there's one who will respond.
                                       -- The Blue Cliff Record

View raw message