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
