Suggestions for further development#

Could JSPWiki use a JDBC datastore to store the pages with histories?

I hope this is the right place to leave this comment..

I'm using the jspwiki as an internal documentation and communication platform - it works great! After convincing my collegues, now of course the enhancment request are flowing. I' am willing to contribute but would like to check these ideas with you - please comment.

I would suggest the following enhancements

  • Keep everything plain and simple
    • Heh. You know, you can't request this and the other things at the same time; any added functionality always adds complexity :-).
  • Move hard coded text from jsp's to template or property file (I was forced to create a patched version of jspwiki to make a complete i18n happen - e.g 'Edit this page')
    • Yes, we know, but so far i18n has not been very high on the priority list.
      • I would be very interested in this patched version, i18n is very high on my priority list. Can you contact me?
  • Create a standard link in top area: Printer friendly (e.g. reduce page with, no menu, simple header)
  • Create a standard link in top area: View as PDF (create xml from page and create pdf via fop - if the created page would be formed as xhtml one could also write a wrapper for this with very less efford)
  • Create templates for formating
    • I changed the layout of our wiki to provide some eye candy - in some areas i would like to be able to force the creation of special xhtml fragments
    • Then why don't you submit your template as a ContributedTemplate? Other than that, I don't really understand what you mean about xhtml fragments.
  • Page and attachment management
    • How to delete an attachment?
    • How to delete a page?
    • Currently, you go the repository and do it by hand. In 2.2, there will be a possibility to do this using the wiki itself.
  • Enhance images to be able to force inlining or linking regardless of image format


I would suggest:

  • remove logic from toplevel jsps move them to classes (servlets,actions). So that they can be compiled and tested.
  • Use relative paths from the document root for data. So that the distrobuted webapp can be easly installed as a homegene piece of software.
  • No need to assamble the webapplication from different directories (etc,src/webdocs,..) in complicated ant builds. just put the webapp like it is in cvs. This way a developer can set his compiler output path to WEB-INF/classes directory, compile jsps inside his ide, etc. (KeepItSimple). The longer it takes to setup the envoriment and seeing the first hacks the fewer will contribute.
  • I don't think that struts is needed because struts more suitable for applications with lots of fine grained actions. however this doesn't mean that the struts libaries can't be used (tiles,beanutils,etc).
  • More unit tests.
  • I like the point about the source structure. Modern IDE's (IntelliJ, Eclipse, WSAD, ...) support webapplications very well, when the source structure is right - like a war file.
  • I also don't think that struts is needed. You have to implement the difficult stuff (authorization, file storage, file locking, workflow, rendering, plugin infrastructure, plugins) by yourself anyway.
--IngoAdler 10-May-2004

Making editing easier#

As a great fan of Wiki and JSPWiki especially, I do find that it can use some improvements. We use JSPWiki with a quite a group of people of various levels. Most people just love them. One thing seems to be a problem and that is the formatting: It seems that new editors use a lot of forced line breaks to format their text, while more advanced people start using a lot of unordered lists. It is awkwuard: Why not use a single linebreak as a break and a double as a paragraph. I did some testing and it is much more natural to type some text. I hope you agree...

-- Jeroen Zomer

I have done a source edit to let you do just that, it was driven by a more technical-based Wiki where single line breaks made more sense. The edit makes this behaviour an option in the preferences, when I asked about it before, there wasn't much interest in putting it into the official distribution though. Feel free to mail me if you want it, I might put it on my page at some point. -- KieronWilkinson

Using Struts?#

Using Struts as a framework for the JSPWiki would make the design much cleaner, and the separation between control and view that is the major advantage by Struts is exactly what is missing in the code on this.

I think that the number of features and the ideas behind this wiki is impressive, but I think that Struts would really bring this wiki a major step forward. For instance it would be extremely easy to implement the authentication and file attachments features if this JSPwiki was based on Struts. --Mortena

I'm doing a light reread of the Struts documentation again. Does it have some sort of explicit support for auth and attachments, or are they particularly easy to implement with Actions? --ebu

The documentation of Struts sucks!!! so don't expect to get to much help from there. The authentication can be carried out by making a form based entrance, and then after that letting a bean in the session tell about the user's identity. Before a page is shown this identity can be controlled in an action.

The attachments can be uploaded very easily with the org.apache.struts.upload package that uploads a DiskFile, that can be easily saved on disk.

The real advantage of struts over other frameworks is its design, and maturity, but the other MVC frameworks (stxx, velocity and maverick) should also be investigated. --Mortena

My opinion is that...#

I think that it is necessary to use a framework like Struts, Maverick or Stxx to make the design more clear, and to speed up the development. I have used Struts and Stxx in a project and think that it works OK, Stxx doesn't seem to be mature enough yet.


I'd like to point out that the speed of development of JSPWiki varies much more greatly according to my day-to-day interest and available time, than the used framework. In fact, switching to some framework is likely to slow the JSPWiki development, simply because it takes time for one to familiarize oneself with a new system.

We actually already have functional attachments and authentication code. I have just been too busy to integrate it into JSPWiki. If I had to deal with JakartaStruts as well - you'd probably never ever see code like that.

Besides, we have pretty clear MVC separation right now - it's not the same as in Struts, but it is there. You can think of "Model" as all of the Java code inside the system. "View" is composed of the JSP templates and "Controller" is the set of the top-level JSP files.

Anyway, since when was "speed of development" a good thing? ;-)

On a more general note: everyone has, of course, their own ideas on how to "bring JSPWiki a major step forward". For Mortena, it's using a standard MVC framework. For AlainRavet, it's allowing HTML. I am not saying that these are not important issues, but what I am saying is that we should keep things simple. I was very dubious about converting into JspTags, but in the end I could see no other way to do this relatively cleanly (except via a total conversion to JakartaVelocity). So it happened. At the moment I am not seeing any pressing need for any framework, so I'm not doing it.

But hey, it's open source! You are entirely free to take the JSPWiki code and make it what you will (observing GPL restrictions, of course). :-)


I think Struts is pretty heavyweight and would probably be over-kill for our needs. I use Struts daily at work. It's pretty good for large, complex web applications, but if you think about it, JspWiki doesn't really consist of much in terms of the web interface (front-end) aspect of things. Not many forms, hardly any validation, simple presentation, very few (<10?) jsps, and pretty simple logic connecting the screens together. In contrast, my project at work consists of hundreds of screens with very complex logic governing the flow between them.

MVC in a web app context is about "separation of concerns", and the current architecture is pretty sufficient in that context. (Althought it sort of bugs me that jsps are used as a controller instead of a "real" servlet).

Yeah... If I had known of Jakarta Velocity before I started JSPWiki, we would probably have VWiki or something right now. The "JSP as controller" -idea was something I wanted to test. It makes some things easier, and some things more difficult. Though as JSPWiki grows more complex, the limits of JSP are suddenly showing (for example, difficulty of code reuse), and thus we probably want to change to a servlet-solution in 3.0. But at the moment we're managing quite well with the current architecture. --JanneJalkanen

Most of the magic in the wiki is in the back end processing anyways.

-- KenLiu, 13-Jan-03

Struts may indeed be overkill for JSPWiki. But there is a difference between JSPWiki using Struts itself and JSPWiki being embedded within another web application that does use Struts. That is the case with our development team's web site (not available outside our firewall). We use Struts (and Tiles, too) practically all of our webapps, the expertise is abundant, and we like it. I took it upon myself to embed Wiki within our site, but it does not get to be the "whole page". Since all of the templates contain complete HTML files, they have to be edited (which is what templates are for, I know). Another, more serious problem, is that internal code reference actions as Wiki.jsp or Edit.jsp. I have modified WikiEngine to read these actions from the file so that our site can use instead of Wiki.jsp. I'll send my patch to Janne separately.

--MichaelRoberts 12-Feb-04

ebu: Yup. I've got to say that everything2's idea of connecting weights to links and adjusting according to popularity, cross-linkedness, etc. is appealing. I wonder if that's too heavy-weight for this.

JanneJalkanen: Everything2 is very, very complex, not to mention difficult to navigate. I personally like the simplicity of WikiWiki.

AnthonyWilkinson: We have created a very simple plugin as an alternative "referenced by" list that orders by number of links. This has the effect that more general topics tend to rise to the top. The first modification to this was to ignore person names (actually links from the "People" page) because these all end up at the top of the list.

ebu: Agreed - the pages are too cluttered and slow at E2. I was thinking more in the terms of unseen but useful search engine features.

ebu ...and in the meanwhile I'll see if I can arrange a version conflict. ;) I lost the original links, but found Let's see... hm.

  • Perl-based (rgh)
  • regexp searches (well, we have ORO)
  • 'collections' (looks like an automated subject division with some authentication - ok)
  • variables on pages (Hmm.. this starts getting complicated again. I'd skip this.)

Janne: A pretty much complete list of all available Wiki engines is at However, what we'd probably discuss about is what this particular Wiki needs. Check TODOList, it has some ideas already.

Asser: This is not bad at all. The site can be maintained quite easily in terms of content because users can fix most problems immediately just by clicking a link for the editor. Pretty neat platform for FAQs I reckon.

Asser: I went through some other Wiki sites and they were pretty impressive :) For instance ExtremeProgrammingRoadmap is a good resource for eXtreme Programming and GreenCheese can be referred for style guides. In my opinion Wiki is definitely better solution for a Regex bulletin board than any 'KnowlegeSpider' (with all the respect for those working with the Spiders).

Janne: I agree. The whole Wiki idea is that it's very fast and convenient. It works on ANY browser, and is accessible anywhere in the world, including client sites with otherwise limited access. Due to its nature, it's also very easy to correct and append to someone else's text (for example, I just corrected a small typo in your text.) (I just corrected a small typo in yours too and 3 more in Asser's - anon)


tuomasp: One question so far. Should new text/questions/etc. append to the top or to bottom? why? (please move this item accordingly, or maybe even add it to the FAQ.)

JanneJalkanen: I don't really know. You can always see what's new with the More Info... link at the bottom, but we need to establish some generic guide rules. Whatever is more Wikilike should be the norm :). I guess most people sort of expect new stuff to be at the bottom, and having new stuff in the bottom prevents pages from growing too big (at some point someone will refactor it when they get tired of scrolling...), but top is easier and faster. Your opinions?

tuomasp: Maybe bottom then, BUT I'd like to see something like datestamps or so telling when the conversation in question has been started. Like this one now.

I think that in the end it does not matter. Of course you can have timestamps - this is after all editable by all. But in a few months the timestamps don't matter, and if you really need them, you'll get them from the RCS logs anyway. Automatical timestamps are a bit harder.

Andreas Rozek: Sorry...this might be the wrong place to ask a probably silly question, but: I just installed JSPWiki on a LiteWebServer and would like to get rid of the "left menu" - as it makes Wiki pages hard to print!
How can I achieve that?

Thanks for your effort

JanneJalkanen: Well, in theory that is easy: you just replace the "LeftMenu.jsp" and the "LeftMenuFooter.jsp" with empty files, or edit the Wiki.jsp directly. Or you can use the page collater by MahlenMorris, codenamed Hula.

MahlenMorris: See, specifically, the printwikistart.jsp and printwikishow.jsp pages in the Hula download. You will need to modify them a bit to work with your wiki (change the server location and so on). Note that this also requires that you set up JSPWiki's WikiRPCInterface, but the other Hula features may make that worthwhile to you :).

By the way, Janne, I was doing a presentation to our engineering group with the Wiki on the big screen, and because someone asked, I had to "explain" that, no, I didn't put in the Australian "G'day" on the page, the Finnish developer did! Like most of my explanations, it only served to confuse people :)

AndreasRozek: Thanks for the quick replies! I decided to try editing "Wiki.jsp" - and succeded! Everything works fine now! Thanks again for your effort!

MikeMorris: There's a much simpler way than editing the jsp's: Just change the css style for td.leftmenu, and add a line display: none; Presto!

Make a PDA-Wiki.#

A PDA-Wiki must be able to provide a special UI for PDA-users with a little screen, so that these users can add content to the Wiki from their PDA, and a normal UI for PC users, so that these users can edit the wiki in a normal way. This can be used as a "perfect" notebook.

Here is the requirements for such a PDA-enabled Wiki:

  • The user must be able to see and edit the Wiki from an Online PDA with a standard HTML browser.
  • The user must be able to do the same from a machine with a normal sized screen to.

The changes needed for this are (probably) only to change the look and feel (size of editor etc.) of a wiki like this, but if there must be different views for different users another approach might be needed.


Offline or online browsing with PDA? Anyway, with the new template system it should be quite possible to provide a PDA-optimized version of JSPWiki. We just need to provide the users with a way to actually set the template they want to use, which is not currently possible :-). The chosen template should be stored in a cookie so that you can modify the behaviour on a per-browser-basis.

Any takers? See JSPWikiFaceLift if you want to help...


Here's an outline of what must be done:

  • Make it possible for the user to choose between two views at the entrance of a wiki or
    • Can be done by running two Wikis on the same source.
      • Not recommended due to synchronization issues.
    • Yes, I'm doing this before actual 2.0 release. --JanneJalkanen
  • To automatically redirect the user to the correct view.
    • Can be made by looking at the browser - version.
    • Better be done by cookies, so that each user can decide which version to view using which browser.
  • To implement the special PDA-view.
    • Can be done by editing the *.css files.
      • Nope. Many PDA-browsers do not support CSS at all. Better done by making a new WikiTemplate.

Please edit the list above, and write your names if you start doing some of the things. Greetings Mortena

I'd like to switch to JSPWiki from I have a lot of data in my PHPWikis that does outlines with mixed numbers and bullets like this:

Using list markup to make an outline....

  1. First thing
    • More info about this
    • And don't forget that
  2. Second thing
  3. thrid thing
  4. Fourth item
    • More info
      • More info about more info
  5. Last thing

The problem here is the numbers should not start over like they do.

Please help. Thanks! -- MattPayne, 9/28/3

Yeah, it's a known bug. There's a bit of discussion at IdeasTextFormattingRules. --JanneJalkanen


As people bump in, we're getting the occasional defacement, spreading test pages, and even some budding page collections quite unrelated to the jspwiki site. I notice that today we got Bev's family tree project (which I assume everyone agrees is not really a jspwiki thing - this is not a public information repository, even if it is publically available), and discussion about advertising in UML Tools.

I assume part of the problem is the fact that we have no clearly delineated subject for the site.

UML tools more or less touch the general bias toward (Java) development and design found on this site. But... where do we draw the line? What do we want this site to be? Purely JSPWiki development discussion, documentation, and distribution? In that case, we already have a bit of cruft - mostly remnants of the early days, when we collected generic java information and tips.

Or, something more encompassing? Java tips? (I personally feel the several good resources out there - Sun's documentation and forums, the Server Side, IBM's DeveloperWorks, the Java Ranch - so maybe a bit of cleanup would be good.)

Personally, I'd see it's Janne's call to decide on some fundamental guidelines, and that of all actives to blast him with the good ideas. Representing the service provider, I'd like to set one restriction: jspwiki should not be a free-for-all-subjects repository, ranging from family trees to cricket scores. ;)

Get ready, get set, go; --ebu


I'd like to be able to "lock" some page contents from not being editable, while still allowing future page editors to add comments and edit the "not locked" page contents. Locked page contents could be unlocked by select users - perhaps only the wiki administrator/owner.

-- DirkSchreckmann

I have such functionality enabled at my weblog. This is possible to do with 2.1.

-- JanneJalkanen

Anyone know of a site which gives a simple comparison between wiki implementations? AndrewCates


AnthonyWilkinson: It would be good to be able to hook into wiki events to integrate it better into a larger environment. I'd like to be able to create a plugin with a method that runs on each edit (or view, preview, etc) to generate notifications - to a chat system, email system, an external log system, etc. At the moment, this would require changing JSPs which has any number of issues, not least of which being that upgrading would become more difficult.


Why can't I create a link that has a target? If I leave the wiki, I want to make sure that a new window is opened, else it is not very interesting to provide exit links.


It seems like JSPWiki does not pass W3C validation:. Is this necessary? I *much* prefer valid xhtml/css systems.

_A_: 2.3.x series passes validation.



A: No need to shout. JSPWiki integrates with Struts just like any other web application. I would investigate the JSPWiki tag libraries for further information. Download the latest source release and look for


I have made a copy of the default template and done some customization for my needs. It works well. However, I have come accross a customization that is a little deeper than rearanging divs or changing color schemes. I would like to use YAHOO's js tree view control to display the left menu. I could parse the text of the page in the LeftMenu.jsp page and write out all the tree view code. I'm pretty sure that somewhere, the JSPWiki library already has an api for parsing the text though. If so, I'd rather make use of that. Where should I start looking?


Look at the MarkupParser class for 2.3.x, and TranslatorReader class for 2.2.x. In any case, the code for TranslateTag is probably what you really are after.

-- JanneJalkanen

Suggestions for further development: Applet-API#

  • motivation
    • To improve the wiki-functionality it would be great the ability to integrate the numberless java-applets out there.
  • actual situation
    • You have to build an wrapper-plugin around the applet ( AppletPlugin has bugs),
    • the admin has to install each plugin (optionally to edit the property searchPath),
    • the user has for each applet to know it's own plugin-tag-scheme with it's own usability.
  • And therefor: a common Applet-API with parametrization of:
    • display-properties like width, height, etc (optional, with default-value)
    • bypassing applet-arguments (xml-structure?)
    • security-concept-issue: must the applet be installed in the webapps/applet-folder or can it attached to the page (

-- thx bZi (05/Jul/08)

Testing Comment functionality.

--AnonymousCoward, 18-Feb-2010 08:58

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
08-09房地产调控反思和预期.pdf 280.0 kB 1 31-Oct-2008 05:53 卡蓝
« This page (revision-154) was last changed on 18-Feb-2010 08:58 by AnonymousCoward