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 Putting the 'JSP' in JSPWiki 3
Date Mon, 11 Feb 2008 16:01:04 GMT
All --

I've been working hard on the second part of the core JSPWiki/Stripes  
integration for version 3. The core integration has been working  
nicely for a while. Unit tests are running nearly clean (4 failures, 1  
error).

Two weeks ago, I shifted my efforts to the JSP/user tier. In the  
absence of a 3.0 branch on the Apache SVN server (a continuing  
annoyance, might I add, but it looks like it will be addressed soon),  
I thought I'd share a few thoughts on a few key JSP-tier changes I'm  
contemplating. They are actually more than "contemplations," in the  
sense that I have them running now. But nothing is etched in stone  
yet. I wanted to mention three of the most important changes so that I  
could get some comments from all of you.

First, I'm doing quite a bit of experimentation with JSP expression  
language. The idea is to use EL variables quite a bit more. For  
example, it's very convenient to be able to simply express something  
like ${wikiSession.userPrincipal} and have it print out the value --  
without needing scriptlet code, or even JSP tags. For the moment, I  
have rigged it so that we inject some standard variables into every  
JSP that invokes a WikiContext (WikiActionBean, really).  Overall, the  
goal is to provide some nice "scaffolding" variables so that JSP  
template authors (including the JSP dev team, of course) doesn't need  
to write much, if any, scriptlet code.

In my local builds, here are the names of the attributes that JSPWiki  
injects into the PageContext request scope automatically:

- "wikiEngine"
- "wikiSession"
- "wikiActionBean" (aka the wiki context)
-" wikiPage" (if action bean is a wiki context, it's set to its page;  
otherwise the front page)

All of these are available as EL variables (e.g., ${wikiEngine}, $ 
{wikiPage}).

You might be asking, how do we "rig" it so that these variables are  
injected into request scope? Excellent question.

That brings me to the second part of the changes -- the introduction  
of the "WikiInterceptor," which intercepts the Stripes ActionBean  
resolution process and does a bunch of magic. As you may know from my  
previous writings (and from the Stripes website), when Stripes sees a  
&lt;stripes:useActionBean&gt; tag in a JSP -- or filters a URL that  
ends in .action -- it tries to find and inject the correct ActionBean  
into the request. In JSPWiki 3, WikiContexts are a type of ActionBean.  
In our case, I have configured Stripes so that when it finds our  
WikiContext/WikiActionBean, it causes WikiInterceptor to fire and to  
our extra magic.

Here's what it does. WikiInterceptor's intercept() methods fires after  
the correct ActionBean is resolved, but before the user actually sees  
the JSP. The interceptor:
- Examines whether the user's desired event handler ("view", "save"  
etc.) requires a particular Permission to execute
- If the event handler requires a Permission, it checks to see whether  
the user possess it
- If not, the user is redirected to the login page
- If yes, it injects variables for the WikiEngine, WikiSession,  
resolved WikiActionBean, and WikiPage (if the action bean is a wiki  
context)

What this means, practically speaking, is that top-level JSPs are  
about to get a LOT slimmer. They won't need to do anything special to  
look up common objects like the WikiEngine, and won't have the need to  
do any access-checking. The various *Content JSPs will likely get  
slimmer too.

Speaking of JSPs, let me speak briefly about the third big change.

Bug [JSPWiki-81] requires us to move JSPs that aren't supposed to be  
instantiated directly into WEB-INF. I am doing this now. In addition  
to having security benefits, this also simplifies the JSP template  
directory a bit. It  means also that PageActions, commonheader, etc.  
all move inside WEB-INF.

The path I'm using for the template-specific JSPs is WEB-INF/jsp/ 
templates/default. So far, I've been able to move the necessary JSPs  
into WEB-INF without requiring many changes. The principal changes  
I've needed to make to the template-specific JSPs included:
- Replacing scriptlet code with ${} variables, where appropriate
- Removal of &lt;fmt:setBundle basename="templates.default"&gt; and  
LocaleSupport.getLocalizedMessage() -- because we set the default in  
web.xml, and because Stripes sets the request locale automatically
- Replacement of WikiContext c =  
WikiContext.findContext( pageContext ) with the newer technique  
WikiContext c = (WikiContext)WikiInterceptor.findActionBean();

Top-level JSPs also change quite a bit. Here, for example, is the  
*complete* contents of Wiki.jsp (angle brackets omitted):

%@ page contentType="text/html;charset=UTF-8" language="java" %
%@ taglib uri="http://stripes.sourceforge.net/stripes.tld"  
prefix="stripes" %
%@ taglib uri="/WEB-INF/jspwiki.tld" prefix="wiki" %

stripes:useActionBean  
beanclass="com.ecyrd.jspwiki.action.ViewActionBean" /
stripes:layout-render name="/WEB-INF/jsp/templates/default/ 
ViewTemplate.jsp"
stripes:layout-component name="contents"
      wiki:Include page="/WEB-INF/jsp/templates/default/ 
PageContent.jsp" /
/stripes:layout-component
/stripes:layout-render

At the moment, the paths for the template JSPs are hard-coded. This  
will change, though. I will massage the wiki:include tag a bit until  
it behaves properly. I think it might also be useful to set up an EL  
variable that makes getting template resources easy. For example, a  
map-style variable expression would be elegant and concise:

${templateResources["PageContent.jsp"]}

The expression would return the correct path, namely /WEB-INF/jsp/ 
templates/default/PageContent.jsp.

Overall, my goal is to make the existing tags work just the way they  
do now, taking into account the new location for JSPs. But I think it  
might be nice, also, to use EL variables as aggressively as we can,  
and deprecate certain tags over time.

What do you think? I welcome your comments and feedback, as always.

Andrew

Mime
View raw message