incubator-jspwiki-dev mailing list archives

> Now, I am not trying to persuade you to use the Stripes URLBuilder.
> However, I mention it in detail to show you that it shares one
> property with what you outlined. Namely, the principle of passing
> parameters as separate arguments rather than the way we do now, as
> a monolithic blob. This is a nice departure from what we have done,
> but it's going to require us to blow up the URLConstructor class
> (as we know it) and substitute something else. Either
> SimpleURLConstructor or the Stripes alternative. I happen to like
> the Stripes URLBuilder because it has taken localization and multi-
> valued properties into account, and does not rely on "magic
> parameters" where authors would have to remember to supply an even
> number of varargs (the first arg is the param, the second is the
> value). Anyway, you might want to take a look at the source code
> for URLBuilder. :)
I don't mind getting rid of URLConstructor, since it's a complicated
thing which does not really work.
I'm not too sure on the URLBuilder as well, since it makes it hard to
just simply to "get an URL, dammit." Yes, it's flexible, but it's
also, well, clunky.
> One thing I think we should look carefully at is whether we should
> keep the getURL() functions onto the WikiContext (aka the
> ActionBean) or move it elsewhere. My feeling is that we should
> deprecate WikiContext-level getURL() type methods and move them to
> the ActionBeanContext, which is associated with each ActionBean.
> That's where all of the HTTP-related stuff is, and I would rather
> keep the ActionBeans focused on functionality (bean properties and
> events) rather than the HTTP-related aspects of how they are
> presented. WikiContext.getURL() will be around for a while (for
> backwards compatibility reasons) but it should delegate to
> WikiActionBeanContext.getURL(). Same for WikiContext.getHttpRequest
> (), which should delegate to ActionBean.getRequest().
Did you take a look at the new API proposal in SVN? I think we
should build a good API library first, so that we can have more
freedom in building our internal core.
Note that it currently has no reference to Stripes or, well, any
other library.
>> Example: in my local builds each ActionBean has an annotation
>> called @URLBinding that says how Stripes should map the 'bean to
>> URLs. For example ViewActionBean's URLBinding is "/Wiki.action".
>> The top-level JSP is easily calculated by chopping off .action and
>> attaching ".jsp". Thus: Wiki.jsp. The content page is *generally*
>> the top-level JSP name plus "Content". So -- that's the rule. Look
>> up the URLBinding, chop off .action, and attach the suffix. "/
>> WikiContent.jsp" would be the default by convention. (Except that
>> Wiki.jsp's content page is PageContent.jsp... so for ContentTag
>> you tell it to use PageContent.jsp.)
Hm. There's one problem with Stripes which I don't like and it's the
fact that it muddles the URLs. If you enter with Wiki.jsp - then you
e.g. run validation on a form, you end up on Wiki.action.
This has the problem that then when someone grabs the URL and sends
it via email, someone else is going to end up with a non-functional URL.
So I would very much like to try and avoid using the Stripes-specific
URLs for *anything*. Relying on any particular Stripes-generated
URLs will also make us essentially stuck on Stripes, too.
> Pulling back from the detail, though, it is clear that certain
> things are going to break. But maybe less than we thought. My first
> attempt at Stripes integration made no attempt to be backwards
> compatible, and indeed, I made it deliberately incompatible with
> those features I did not like (e.g. URLConstructors, Commands).
> That was clearly too ambitious. My approach now is to keep as much
> compatibility as possible but aggressively deprecate methods or
> fields where the alternatives are better. WikiContext request
> contexts are one example.
Commands we can get rid of, yuck. They should absolutely be replaced
by ActionBeans.
> In my copious free time, I have been taking another whack at 3.0.
> The primary incompatibilities are the removal of the WikiContext
> contructor (use a factory instead) and the related setRequestContext
> () method. In fact, if it is not too late, I would not mind
> removing the WikiContext constructor NOW, in 2.8, and forcing the
> use of WikiEngine.createContext(). That's only a few cases
> (15-20?), and there is little/no exposure in the JSPs.
I wouldn't, since it's the officially promoted way to e.g. use the
renderer engine in embedding systems. We can't break that one until
3.0.
> The other major difficulty is the historical "overloading" of
> WikiContext to include non-page-related activities like groups and
> user maintenance. This is a little harder to tackle, but it should
> only affect about 30-40 places in the code.
The big problem is that WikiContext is a part of our official API, so
we can't remove any of that stuff.
But let's work on the API in the SVN - we still have time.
/Janne