incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.jaqu...@mac.com>
Subject Re: REST-ful URLs [Was: url rewriting supported?]
Date Fri, 11 Jul 2008 14:49:53 GMT
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

Mime
View raw message