Simon Kitching wrote:
The first issue I expect to strike is that the url triggering jspwiki
will be of form "/ourwebapp/help/Wiki.jsp?page=ZZZ". Does jspwiki run ok
under a path that is not the webapp root?
I guess I can figure it out myself (the code is *wonderfully* well
commented) but whatever is easy for you to provide would be greatly
appreciated.
I had another thought, could you just deploy JSPWiki as a standalone JAR
and set it's context path to "/ourwebapp/help/"? If that's doable in
whatever appserver you're using then you wouldn't need to patch at all.
I suspect the core developers will be pretty busy with the move to
Apache over the next few weeks, and probably aren't too keen on patches
to change things like this at the current time..
Sort of my thoughts at the time I wrote the code.
Aren't most of the jsps needed even in just read-only mode? I can see
how the "controller" pages Wiki.jsp, Edit.jsp, etc can be replaced with
servlets fairly easily. But as I currently understand the code, a lot of
the others (eg ViewTemplate.jsp, ViewContent.jsp) are critical for
correct rendering of a page, even when WikiRenderer is called directly.
Have I misunderstood something?
The renderer simply produces HTML from the source wiki text. We have our
own pages (JSPs) that call the WikiRender, get the HTML and insert it.
Naturally this doesn't use any of the templates, or display the left
side nav, etc.
And with an unpacked approach, how do you handle an upgrade to a new
JspWiki release?
As long as our code compiles against the JSPWiki JAR, we can just swap
that out on the read-only site. On the admin site, we'd have to copy
various pages to be included in our WAR. We generally grab the files we
need from CVS.
-n
