#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:
I think it is a hard requirement, for the following reasons:
1) JCR uses slashes to denote paths.
2) Slashes are the Web de-facto standard for denoting hierarchy
3) As Murray points out in his mail, the URL schema is the single
most important API contract that we have, so we should design that to
be good first, *then* figure out how to implement it. Exposing
implementation detail is not a good thing there.
4) WebDAV uses slashed to denote paths (which means that if we choose
to continue to develop the WebDAV API, it would be completely
different. At the moment, our attachments are WebDAV endpoints -
yes, you can PROPFIND on an /attach/Main/foo.jpg if you want to.)
5) We are already using slashes to denote attachments.
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.
Yes, this is correct. And our WikiServlet covers nicely all other
URL schemes.
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?
Wrong. It still won't cover the subpages or attachments. Also, it
won't cover Murray's requirement.
(I've written two Stripes applications in the meantime ;-)
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.
So you're saying that we should not allow pluggable URI schemes?
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.
Stripes does care, and I don't think we can use anything else.
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.
I disagree. It won't give us a better request binding (as you point
out, Stripes will be entirely happy to bind stuff with almost any URL
with stripes:useActionBean - and the only real problem is the "page"
parameter - everything else is a regular query string). It won't
give us forward compatibility because it cannot work with subpages,
and it won't give us backwards compatibility in the case someone is
using something else than Default or ShortViewURLConstructors.
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!)
I don't think so. I think we would be shifting complexity from one
layer to another, and removing features and introducing a faulty URL
scheme, forcing people like Murray to use Apache as a front-end.
/Janne
