Janne --
I have done some in-depth testing of clean URLs in Stripes 1.5-RC1.
Based on my testing, I have concluded that there are several new facts
you should be aware of.
1) Stripes clean URLs supports slashes inside of extracted parameters.
That means sub-pages ("Foo/Bar/TestPage"), can be passed and they will
be extracted. The existing (in my 3.0 branch) WikiPageTypeConverter
would only need a small enhancement to properly locate pages with
hierarchical paths.
2) When using the Stripes URLBuilder with an ActionBean, it constructs
clean URLs, well, cleanly. Parameters not otherwise specified in the
pattern are sensibly appended to the generated URL, as you would
expect. This is good.
3) The Stripes UrlBindingFactory class that matches incoming URLs with
UrlBindings does not use regular expressions, and looks fairly well-
written and efficient. It does NOT, at this time, parse parameters
appended to the clean URL. I have uploaded a patch to the Stripes JIRA
site that adds this enhancement.
4) The UrlBindingFactory has many helper methods for parsing URLs that
do NOT depend on @URLBinding class annotations. In particular, this
means that URL binding definitions could be provided from an external
source -- for example, a config file.
The cumulative effect of these facts means that the Stripes approach
is viable. In short, I think you should re-consider your previous
objections. :)
Now, as to your comments:
I think it is a hard requirement, for the following reasons:
As I mentioned, my testing shows that clean URL parameter values that
contain slashes are parsed correctly. You previously stated that
"Stripes cannot guess when a slash is a part of a page name, and when
it is an action." I assure you that it can, and with the ShortURL
scheme in particular.
Wrong. It still won't cover the subpages or attachments. Also, it
won't cover Murray's requirement.
It does. Also Murray and I have been talking about his requirements
offline, and he is satisfied.
So you're saying that we should not allow pluggable URI schemes?
You have previously stated that the "URL contract" is one of the most
important "contracts" we have. I agree. However, that does not
reconcile with your desire to have allowing pluggable URL schemes.
I happen to believe that URL scheme pluggability is NOT important. We
should pick a good URL scheme (e.g., based on ShortURLs) and stick
with it. And I am quite happy to enshrine the ShortURL scheme in code,
as ActionBean annotations. The "long URL" case, as we have agreed, is
already covered. We will have to disagree on this point.
That said, as I mentioned, UrlBindingFactory has the capabilities to
allow us to add other bindings, not just those specified in the
annotations.
I disagree. It won't give us a better request binding (as you point
out, Stripes will
It might. Have you looked at the URLConstructor code lately? There's
more 'ifs' in those classes than a busload of wishful thinkers.
and it won't give us backwards compatibility in the case someone is
using something else than Default or ShortViewURLConstructors.
Our implementation choices should not be constrained by edge cases
that depart from the URL schemes that JSPWiki supports out of the box.
Our compatibility contract is with our existing, URL schemes, not
hypothetical outside ones.
That said, for those websites who choose to depart from the three
established URL schemes (short, long aka default, and shortview),
mod_rewrite is always an alternative. So too is a NON-annotation
driven approach that externalizes the URL binding definitions and
loads them up into URLBindingFactory.
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
Indeed, this whole discussion has been about exactly that -- shifting
responsibility from a series of hard-coded classes that are inelegant
and brittle to something better. When has that stopped us before?
Two last points:
First, the whole debate about using @UrlBindings in ActionBeans is
kind of academic, because **even if we do nothing*** Stripes will use
its own default URL binding scheme. For example, let's say we have
PageActionBean, a hypothetical ActionBean that would hold our view-
page logic. Without an @UrlBinding annotation, Stripes will
automatically bind the bean to Page.action.
You have previously said that you were unhappy about this. Ok, then --
let's try and put it into a format that is more JSPWiki-like.
Second, I believe the UrlBindingFactory class has us covered for
alternative cases where users wish to use an alternative URL parsing/
generation scheme. These definitions could be externalized to a config
file, for example, and loaded into the factory at runtime via the
public method UrlBindingFactory.addBinding(beanType, binding). Stripes
will happily use these bindings too. DAV could be externalized this
way. So could other implementations. And they would all use the same
syntax, which is EL-like, very powerful, and in my view quite nice.
Imagine we had an urlbindings.properties file. We could put stuff in
it that looked like this:
PageActionBean.class=/wiki/{page}/?do={$event}
GroupActionBean.class=/groups/{group}/?do={$event}
You could add DAV bindings too, and any other bindings the user
wanted. Nice and declarative. Doing it this way would be much more
flexible than code, and would provide ways to supplement the default
URL bindings with other ones.
Think about it, wouldja? :) This could really work -- and simplify our
code base too.
Andrew
