incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.jaqu...@me.com>
Subject More thoughts on Stripes and 3.0
Date Sat, 02 Aug 2008 17:57:12 GMT
Hi everybody --

Been working hard over the last few weeks to re-do the Stripes  
integration with JSPWiki. I did an initial integration about a year  
ago, but it was hard to keep it synchronized with the trunk. The  
number of files that were modified approached 350! This was largely  
because I was (too) aggressive in changing the APIs.

Over the next week or so I will check in a huge batch of code that  
rolls back most of this, and integrates Stripes much more invisibly.  
If the previous attempt touched 350 files, this one touches only about  
50. Not only will  this easier for me to maintain, but it will also be  
less disruptive from an API perspective. The design goal, also, is to  
allow us to migrate JSPs selectively over time.. more on that in a  
future note.

As I check stuff in (to the Stripes branch), I will also probably  
start making appropriate changes to the 3.0 API branch that Janne has  
set up. The changes to the 3.0 API are likely to be fairly minor. New  
items will include an "action" package to hold the ActionBean stuff.

As I have gone through this refactoring exercise, my thinking about  
the relationship between WikiActionBeans and wiki contexts has  
changed. Before, I felt wiki request contexts should correspond  one- 
to-one to WikiActionBean classes. For example, WikiContext.EDIT in 2.x  
would have corresponded to EditActionBean. But this just meant that  
the number of ActionBeans would have to be huge.

Now, I think it would be best if request contexts corresponded to  
Stripes events ("handler event methods"). Practically speaking, what  
this means is that it becomes possible to consolidate handling logic  
for different wiki request contexts into one ActionBean. For example,  
GroupActionBean could contain the logic for ALL group operations, like  
view, edit, delete, create etc.

To give you an idea, practically speaking, of what an event handler  
looks like in this new scheme, imagine an "edit group" handler method  
that implements all of the logic for editing the group. We want this  
to correspond to the VIEW_GROUP context. And we want to be able to  
enforce the correct permissions on callers who attempt to change the  
group (i.e., execute the handler method). Here is the method stub that  
does it:

@HandlesEvent("edit")
@WikiRequestContext("editGroup")
@HandlerPermission(class="com.ecyrd.jspwiki.permission.WikiPermission"  
target="${group.name}",actions="edit")
public Resolution edit()
{
     ... Logic goes here ...
}

While I could go into lots of detail on how the whole request cycle  
works, suffice it to say that the annotations are where all the magic  
are:

1) the @HandlesEvent is how Stripes knows what handler method to execute

2) the @RequestContext method is what maps the event handler method to  
an old-school wiki request context. This is a custom annotation I  
wrote for JSPWiki.

3) the @HandlerPermission is another custom annotation, with EL-style  
syntax, that allows the various JSPWiki access control checkers to  
determine the correct permissions required to execute the handler  
method. Oh, and did I mention that this all works with AJAX too?

All of the foregoing is combined with a nifty WikiActionBeanFactory  
class that locates the right ActionBean+handler method for a given  
request context. At WikiEngine startup, it will auto-discover all  
WikiActionBean implementations on the classpath.

What's cool about this is that it blows up the horrible Command  
classes and replaces them with easily understood annotations that can  
be applied to any ActionBeans we (or end-users) create.  And  
ActionBeans, after all, are just slighty fancy JavaBeans. All bean  
authors need to do is add a few annotations. The security, context  
mapping and event handling is all handled by JSPWiki and Stripes.

I am glossing over a lot, of course, but I thought you might like to  
see where my head is at. Comments and questons are welcome as always.

Andrew

Mime
View raw message