jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Steichen <te...@net-frame.com>
Subject Adding custom JSP modules to JSPWiki (was JSPWiki 'Special Pages')
Date Wed, 28 Nov 2007 19:39:43 GMT
Janne,

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. 

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.

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.

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? 

Terry


Janne Jalkanen wrote:
>
> So, what you are asking is how to create your own Command, so you can 
> influence what the ContentTag outputs?
>
> I don't think that is supported directly, but the easy way would be to 
> extend from ContentTag to support your own top-level JSP files.  That 
> way you should be able to just to either use your own ContentTag or 
> just replace the class name in jspwiki.tld for <wiki:Content>.
>
> If you look at it, ViewTemplate.jsp is really, really simple.  It 
> includes a header, and then defines the basic layout, which is mostly 
> CSS-based anyway.  The idea is that you can very simply "skin" jspwiki 
> by creating a new ViewTemplate.jsp for your own purposes.
>
> Plugins can't load JSPs directly.  This is a known fault with JSP as a 
> technology, and one of the reasons why e.g. Velocity is superior.  If 
> we were using Velocity, we could be using it programmatically everywhere.
>
> /Janne
>
> On Nov 28, 2007, at 17:52 , Terry Steichen wrote:
>
>> Janne,
>>
>> Most client requests to a JSPWiki site pertain to the simple display 
>> of the contents of ordinary wikipages.  (Other types of requests are 
>> handled, not by Wiki.jsp, but by other 'first line' JSP modules, such 
>> as Install, Captcha, SisterSites, Comment, Login, Logout, Preview, 
>> PageModified, PageInfo, Rename, Delete, Search, Message, 
>> UserPreferences, Diff, Vote, EditGroup, LostPassword, Edit, 
>> NewBlogEntry, NewGroup, or Group).
>>
>> For these requests to display the contents of ordinary pages, handled 
>> initially by Wiki.jsp, ViewTemplate.jsp provides the 'look and feel' 
>> aspects that surround the unique content stored in a wikipage. It, in 
>> effect, wraps the unique wikipage content with the standard header, 
>> footer and menus.
>>
>> The challenge I (and others, I think) face is how (within JSPWiki) to 
>> display content from a custom JSP so it has the same look and feel as 
>> wikipages (and to make JSPWiki treat that custom JSP as just another 
>> wikipage).  I mentioned that my (admittedly distasteful) approach was 
>> to modify ViewTemplate.jsp to accomplish this.
>> However, you seem to suggest/imply that there is indeed a way to do 
>> this without having to modify ViewTemplate.jsp.  Could you explain 
>> this could/should be done?  (I ask because if I can accomplish this 
>> without changing ViewTemplate.jsp, I would be more than delighted.)
>>
>> I realize I may be overlooking something very obvious that deserves a 
>> 'duh' response, but I'll take the risk.
>> Terry
>>
>> PS: Maybe via a plugin that directly loads a JSP?
>>
>>
>> Janne Jalkanen wrote:
>>> Any JSP page or plugin can request custom scripts to be added to the
>>> <head> by calling TemplateManager.addResourceRequest().  No need to
>>> rewrite ViewTemplate.
>>>
>>> /Janne
>>>
>>> On Wed, Nov 28, 2007 at 09:48:13AM +0100, Matthias K├Ąppler wrote:
>>>
>>>> Hi,
>>>>
>>>> 2007/11/27, Terry Steichen <terry@net-frame.com>:
>>>>
>>>>> ...  With that
>>>>> caveat, I'll give you a few thoughts on how I use custom JSP pages 
>>>>> with
>>>>> JSPWiki.
>>>>> ...
>>>>>
>>>> Thanks for your explanations.
>>>>
>>>> What was really making trouble was the linking of script files in 
>>>> the JSP
>>>> that will be included as a special page. These scripts would be 
>>>> included as
>>>> part of the "pageContent" DIV, which itself was part of a HTML 
>>>> table and
>>>> HTML does not allow script tags at this point.
>>>> I solved the problem by rewriting ViewTemplate so that in <head> it

>>>> checks
>>>> for the current request context and if it matches my special page, 
>>>> it will
>>>> include a MyCoolPageHeader.jsp containing all script tags. However, 
>>>> this
>>>> means that for every special page I would have to modify 
>>>> ViewTemplate and
>>>> check for some specific request context. Not the most beautiful of
>>>> approaches, but it works.
>>>>
>>>> Having said all this, I invite Andrew to comment.  He's a very 
>>>> smart guy
>>>>
>>>>> who knows a LOT more about security than do I.  There may be some
>>>>> problems in this approach I'm not aware of.  (As I prepare to post 
>>>>> this,
>>>>> I notice that Andrew seems to have shifted his view a bit, but I'd 
>>>>> still
>>>>> like his comments about this approach.)
>>>>>
>>>> Sure. I was just somewhat surprised by his answer, but he already 
>>>> said it
>>>> was a misunderstanding so no problem here. My apologies if I didn't 
>>>> make
>>>> myself clear enough in the first place.
>>>>
>>>> Thanks,
>>>> Matthias
>>>>
>>>
>>>
>
>

Mime
View raw message