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 <[EMAIL PROTECTED]>:
... 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