Interesting thread! You guys had me at a disadvantage -- I was on a
plane from Latin America this morning, and have not been able to
respond until now.
I think I smell a resolution in the air. It is, indeed, to use Stripes
as the "backing technology" for short URLs. Doing this gets us
compatibility with all three current URLConstructors. Here's why:
First, let me state what I think I heard from Janne.
#1: we have to stay compatible with ShortURLConstructor
#2: we have to stay compatible with DefaultURLConstructor too
#3: Janne has no interest in coming up with a new scheme, but is happy
to let "others" (read: Murray) go crazy if they want to, outside of
the core distro
#4: despite restrictions 1, 2, and 3, the URL scheme needs to somehow
accommodate subpages and wiki spaces
#5: we assume that the delimiter for spaces and sub-pages is the same
as the one separating subpath in the URL (/)
Assumption #5 is dubious IMHO, but let's assume all of the others are
hard requirements. Even with these constraints, we can still use
@URLBindings for inbound parsing. Here's why:
DefaultURLConstructor is just the JSP path with appended parameters.
Because every top-level JSP will have a stripes:useActionBean tag in
it, Stripes will automatically do its magic resolve-bind-execute-event
thing regardless, when the JSP is directly addressed. So if we have
URLs that are of the "default" form, we are covered.
As for "short form" URLs, our current URL syntax could be handled by
the "clean URL" @URLBinding syntax quite easily. Janne, you might not
realize this, but the clean URL format is more flexible than you
think. It does not require an exact match; just the firrst part of the
URL needs to match. If the remainder is a series of appended
parameters (in normal '&' syntax), these are bound as normal
parameters. So you do not need to specify an URLBinding that includes
absolutely every parameter you would ever need to bind -- just the
important ones. That is exactly how short URLs work today, no?
So -- if we have 1) the DefaultURLConstructor covered via
stripes:useActionBean and 2) the ShortURLConstructor covered via
URLBindings, then by definition we also have 3)
ShortViewURLConstructor covered. Requirement #3 (other URL schemes) is
not met, but there is always mid_rewrite for those cases.
The wildcard here is what happens with wikispaces and nested pages.
Best case: Stripes does not care what is used as a delimiter, even a
'/'. Worst case: Stripes does care, so we use a different delimiter,
like a colon.
Now, this kind of throws out Murray's particular scenario, but it does
neatly give us, essentially, solid backwards compatibility and much
better request binding, and great forward compatibility. We would
still need an improved URL constructor class for the short URL case,
which would rely on the URLBindings for instructions on how to make
the URLs.
We would effectively be trading code for annotations. Personally, I
think that is a good thing, because it makes it easier to create new
ActionBeans (features!)
Andrew
On Jul 8, 2008, at 12:03 PM, Janne Jalkanen <[EMAIL PROTECTED]>
wrote:
I'm thinking that perhaps Andrew and I might be able to fix it via
Stripes. I don't know how big the library is but if it's not big we
could possibly introduce Stripes into the mix as the backing
technology
for the ShortURLConstructor, which would ease *everyone* into the 3.0
path since they could begin to use the new schema for all new sites
I don't really see any way that we could use Stripes here. And
personally, I would not use a new scheme... So it certainly
wouldn't help my job ;-)
The 'collectionHierarchy' is in the current wiki a single token but
*could* be deeper. Given I don't think we'd want arbitrary depth
(I may be wrong) then there's only the possibility that we might
go from "Main" to "Main/SubMain". That shouldn't be a big problem
if we design the schema such that the verb is either at the very
end or part of the query. So "Main/edit" can only be a page reference
if it's "Main/edit/verb/" (e.g., "Main/edit/edit/") or
"Main/edit/?action=verb". This shouldn't be a problem.
It is, because Stripes CleanURLs assume static paths - item #1 is
always something, item #2 is something else, etc. Stripes cannot
guess when a slash is a part of a page name, and when it is an
action. The CleanURLs are nice, if you are developing an app from
scratch. It's not so nice trying to retrofit existing URLs.
This means a separate parser, and that means an URLConstructor (or
something similar). Which again means that Stripes is nice, but I
think this particular idea is wholly unsuited for the problem at hand.
Well, the URIs *are* already RESTful. ;-)
(In fact, /Edit.jsp?page=Foo is also RESTful. Most people just
like to hide the technology [jsp in this case] by using neutral
URIs like /edit/Foo).
Yes, I have an absolute, unbendable requirement that we have to hide
implementation details from the URLs. So if one's definition of
RESTful
includes hiding implementation details (and mine does), then this
is a
necessity. In my actual case it is a requirement.
Well, you are entitled to define the words anyway you want, but
don't expect us to adhere to the same definitions. JSPWiki is
already RESTful in the commonly agreed definition.
etc. I'd also like to be able to do PUTs via a RESTful interface in
addition to the human UI so we can remotely populate a wiki from an
external site, for synchronization, etc.
I highly recommend that you implement the Atom Publishing Protocol
then. It's pretty much the standard these days. We have the basics
in place, but we should really switch to a better library, since the
current implementation does not support APP 1.0.
The other possibility is to start working on the DAV interface
(which defines all your metadata stuff in a commonly agreed language
instead of redefining the meaning of the HTTP verb HEAD ;-). The
DAV stuff mostly works, but it's client-specific.
Both are REST.
I'm not sure whether we would need a third one.
/Janne
