incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Re: Adding custom JSP modules to JSPWiki (was JSPWiki 'Special Pages')
Date Wed, 28 Nov 2007 19:56:20 GMT
> Creating a customized top-level JSP is indeed one approach to  
> adding customized JSP.  However, my past research (done about 6  
> months ago or so) into this (namely, via the JSPWiki source code)  
> led me to conclude that it would not be easy to extend JSPWiki to  
> include other types of contexts (which ViewTemplates uses to  
> determine what XXXContent.jsp to pass the request to.

No.  ViewTemplate does *not* determine it.  It's the ContentTag which  
does it.  If you extend ContentTag, you get full control over what  
you do.

> Thus, it seemed to me (maybe reflecting an incomplete understanding  
> of the JSPWiki architecture?) that a new top-level command would  
> also need its own equivalent for ViewTemplate and XXContent, along  
> with other ancillary modules.  While, as you say, none of these are  
> really rocket science, as JSPWiki versions changed (and templates  
> along with them), these customized modules would also have to be  
> changed to stay in sync.

No, it doesn't need its own equivalent.  You can use it by extending  
ContentTag.

> After this research, I concluded (rightly or not) that it seemed to  
> be simpler to modify a single JSP, ViewTemplate.jsp.  As I've  
> implemented them, basically all the customization changes are  
> additive and thus can be inserted into each new ViewTemplate pretty  
> easily.

That works, too.  As long as you're willing to sacrifice a bit of  
flexibility (but for a custom app and a custom template, this should  
be an agreeable tradeoff).

>
> As to a plugin not being able to load a JSP, I'm surprised that  
> this can't be done (though I certainly defer to your technical  
> expertise on that).  After all, it's trivial for a JSP to load  
> another JSP.  Is this due to the fact that the plugin is  
> implemented as a Java, rather than JSP, module?
>

Yes.  A JSP needs the full request, response and pageContext - and  
it's rather difficult to create all of them programmatically.  It  
might be possible to create a framework which does that, but I  
haven't seen anyone do it.  The servlet API is really the culprit  
here, as it completely leaves the creation of such things as the  
burden of the container.

However, other templating systems like Velocity allow for  
programmatical construction of the rendering context, which means  
that you can just put in a template and some variables, and get back  
a String.

/Janne

Mime
View raw message