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: Adding custom JSP modules to JSPWiki
Date Wed, 28 Nov 2007 21:01:49 GMT
Yeah. I was just going to pipe in about Stripes -- but stifled the  
thought because it was too philosophical.

Put simply, the Command pattern does exactly what Janne describes. In  
retrospect I think it was a mistake to put them in (you can blame me  
for that). Partly because it welds together top-level JSPs, URL  
patterns and request contexts -- but mostly because it makes it  
JSPWiki harder to extend.

The JSPWiki 3.0 local branch that I've been working on, which uses  
Stripes, makes things much cleaner, simpler AND flexible. Each "wiki  
context" becomes its own ActionBean class. 'Beans can be used in all  
sorts of combinations. It breaks the one-context-for-one-page rule.

Anyway, I think we're going to declare 2.6.0 soon; 2.8 follows  
immediately after, and then we can get to work on the good stuff 3.0.   
Terry, that doesn't help you much in the short term, I know. But know  
that extensibility is going to be a much bigger theme in 3.0.

Andrew

On Nov 28, 2007, at 3:50 PM, Janne Jalkanen wrote:

>> Forgive me if I'm missing something, but when I originally did my  
>> research I did look into extending ContentTag.  However, it seemed  
>> to me that this would in turn also require a modification/extension  
>> of WikiContext, which would in turn require modification/extension  
>> of PageCommand/WikiCommand.  By the time I got to this point, I  
>> decided to give up on this approach.  Was I making it more  
>> complicated than it really is?
>
> Yup.  The Command represents a built-in JSPWiki command, or a  
> RequestContext, or a top-level JSP (or one of the *Content.jsp) - 
> files, which are all more or less different names for the same thing.
>
> The trick would not be to add a new Command, but to simply use some  
> custom logic in your ContentTag subclass, and if it does not match  
> against your own parameters, call the superclass method.
>
>> Regarding the issue of launching a JSP from a plugin (which, if it  
>> could be done, would be, I think, a truly elegant way to do this):  
>> If all that it needs is a request, response and pageContext, could  
>> those be captured and stored as session attributes by (one of) the  
>> original request-handling JSPs (and then accessed and used by the  
>> plugin to launch the JSP)?  Maybe using some of the logic employed  
>> by Velocity, if necessary?
>
> I don't think that is a good idea.  For example, unit testing that  
> without a servlet container would be impossible (or at least very  
> difficult), and it would make that particular plugin non-usable for  
> non-JSP cases.  Also, I would be very hesitant to make the  
> assumption that mucking about with the pagecontext in such a way  
> would be okay.
>
> Velocity bypasses JSP completely, and requires only Servlet  
> support.  It would be a far cleaner and nicer solution, and I know  
> some people are succesfully using Velocity templates with JSPWiki to  
> generate HTML.
>
> Anyway, with Stripes we can get rid of most of this stuff, which is  
> getting too arcane anyway. :-)
>
> /Janne


Mime
View raw message