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:
http://www.acme.com/pages/PageName/get/?param1=name?param2=name
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
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
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
