Please use the SubmitNewIdea page to add a new idea to the idea tracking system (it will be automatically referenced in NewIdea).

This is an archive page of old ideas. Please copy an idea from this page to the new Idea tracking system, you happen to go by.

There is also a place for bug reports. See also RejectedIdeas for ideas that don't seem to fit.

Table of Contents

RefactorMe, please.

Referring Pages #

Attachment Meta Data
Bread Crumbs Idea
Bug Reports
Camel Case
Create Topic When Not Found
Dirk Pessarra
FAQ General
Francois Parlant
Help Wanted
Idea Refactoring The Wiki Engine Class
Idea Wiki Tag For Current Template Absolute Path
Ideas A Redirect To Then Main Page When A User Sets His Username
Ideas A Welcom Message For The Main Page
Ideas Calendar Tag
Ideas External Link Camel Case Matching
Ideas In Page Hyperlinks
Ideas Instant Messaging Wiki
Ideas Internationalization
Ideas Left Menu Footer Should Be A Link Back To The Main JSP Wiki Page
Ideas Link Target Control In Properties File
Ideas Locale Settings
Ideas Metadata
Ideas Multiple Wiki Webs
Ideas Page Aggregator
Ideas Plugin Script Language
Ideas Predefined Edit Textarea Text
Ideas Question Mark Location Presence Icon
Ideas Rename Pages
Ideas Show A Page Hierarchy Like At
Ideas Show Hostname Instead Of IP Address
Ideas Show Question Mark Only For Authorized Users
Ideas Translator Reader Evolution
Ideas Upload Comment
Ideas User Preferences
Ideas WORD_SEPARATORS Should Be Configable
Ideas Wiki Object Editors
Ideas Wiki Refactoring Tools
JSP Wiki Development
JSP Wiki的特性
Kabe Robichaux
Link Type
Old Ideas 1
Page Deletion
Paul Downes
Publish Plugin
Rejected Ideas
Release 2.2 Discussion
Search Enhancements


The Archive contains the snapshots of discussions when archived

Discussions on their own pages#

New Ideas#

29.07.2005 - Personalizeable Left Menue#

Like it is on disposal at, a personalizeable left menu, for each user (registered ones, no guests or unknown users) it is possible that he or she can add favourite links to the left menue, which just appear for this person. This links would really give people the possibility to keep track on the pages of interest.
See also: NewIdeas

23.07.2003 - Currently Logged In User List#

I am using Tomcat's Basic Authentication. It would be cool to be able to display who is logged in to the Wiki at any time. GregSmith

I don't think you can get it easily from the Servlet API. Does anyone have a working example?


You'd need to maintain the information on the server somehow. One option could be a static Map of usernames linked to session IDs. By setting an Object which is an HttpSessionBindingListener into the session when a user logs in, that Object will get notification when the session it is bound to times out so it can remove the session from that Map.


17.07.2003 - Email edit interface#

EmailInput and WikiMailet -- GeertVanDamme

Sometimes you want to work on wiki pages when you're off-line. This might sound contratictory at first, but consider this scheme:

  1. next to the "edit" link, there's an "edit by mail".
  2. hitting that, I get sent an email, where the subject is PageName#Token
  3. the email contains the page text (in bare WikiMarkup - not the html). The token is a unique id generated by the server, which identifies me and the page version.
  4. I reply to that email with my edited text, retaining the subject line.
  5. If the token on the reply matches my email and the current version, it is checked in.
  6. If not, I get a polite error response..

- YishayMor

Not a bad idea at all, but probably something that should be done as an external component instead of a JSPWiki core functionality. For example, this would be a nice exercise for the WikiRPCInterface (though it needs to be amended a bit with saveText() method first). In fact, I would imagine this to be very useful across other wikis as well, so a generic component would probably be a better idea.

-- JanneJalkanen, 17-Jul-2003.

Nice. But I guess you need to be carefuk if the page is changed between sending yourself the email and replying to it...

-- KieronWilkinson, 29-Jan-2003

15.07.2003 - Directories and Access Control#

I'd just like the ability to create directories in the Pages directory. This would allow access control by the container (Tomcat) at the directory level. And it would add a simple Hierarchical structure to the Wiki.

Naming: [Dirname/pagename]

I notice that using a '/' indicates to JSPWiki that the reference is an uploaded file. Possibly a different character can be introduced:

Naming: [Dirname#pagename]

I'd be happy if there were no way for the ordinary user to create the directories on the fly and they had to live with whatever directories existed. But it would not take much work to create a directory whenever you created a new page.


Support for SubPages is slated for 2.4. We just need to get the authentication working and tested first :-). See Ideas - SubPages.

-- JanneJalkanen

10.07.2003 - Finer control of access rights#

We can protect the wiki by page-constraints in the container.
But because alle files are in one directory we cannot protect sub-sections. How about using access roles combined with the Hierarchical Patch to achieve flexible protection by directories?

-- ReinhardMoosauer

Well, the way the WikiProvider stores its pages has nothing to do with the hierarchy of the actual Wiki. But there's a finer access control method already in the CVS version.

-- JanneJalkanen

17.06.2003 - Use Jakarta Slide#

How about using the Jakarta Slide project's framework for content management? It would abstract the storing of pages and also takes care of versioning. Another big bonus is that Slide can expose your content using WebDAV which would make editing a snap!


There's plenty of discussion on WebDav and JSPWiki on Visions already :-). (Perhaps we should make a separate page for it).


05.06.03 - Compact URL via servlet-mapping#

Perhaps I will figure out a way to do this on my own, but I'll post here in case JanneJalkanen finds it interesting enough to implement for all. When sending links via email or dropping them on a presentation slide, brevity is appreciated. Thus, I propose mucking with the web.xml to get URL mappings to work like this...


Yes, I agree. It is something that's on my TODOList, but I haven't yet decided on the implementation.


This would be super-nice! How about writing a very small servlet which is mapped to all requests (/). It could then rewrite the URL in the old way and forward to the JSP.
(Maybe you have to bypass the page-parameter by a request-Attribute. This gives two more lines in Wiki.jsp)


Could this be done using a ServletFilter?


I think so, yes, until we can develop some sort of an official way of compacting the URLs. For 2.1, you could also do it with PageFilters.

-- JanneJalkanen

01.06.03 - Tag Plugin #

The PluginTag is a great idea. How hard would it be to also provide the inverse, i.e., a Plugin I could use to include the output of any JSPWikiTag on my page?

- YishayMor

Well, actually, I tried making one, but the problem is that JSP tags assume that they have a valid JSP PageContext available. Plugins may be executed in a context where there is no PageContext, such as through XML-RPC, or when being embedded. Thus JSPWiki would need to create a dummy PageContext, or else have plugins that are available only when accessed through a web browser (and I think that still you might need the PageContext).

It's not easy either way.

-- JanneJalkanen

I suppose the Q&D way is to document around it. Just add a note saying "this plugin won't work in XML-RPC and embedded".

If you want to implement a dummy PageContext then you can use the Tag setPageContext() method to pass it in. Most context methods deal with attributes, which you would probably delegate to a HashMap. Some methods, like getServletConfig(), you might do good enough to implement by returning null. One remaining issue is the output methods (e.g. pushBody(), popBody(), getOut() which might be a bit tricky.

-- YishayMor

16.05.2003 - Publishing Plugin#

Anybody interested in having a publishing plugin? We're a small IT consulting organization currently utilizing JSPWiki as an internal collaboration tool and also as a means to collect content for our external web site. We'd like to continue utilizing JSPWiki to collaboratively manage the content on our web site, but want to selectively publish a read-only version when necessary. It looks like someone has already written PublishAddOn for TWiki. We might be willing to develop one if there is enough interest and we have enough time.

-- ChrisChesney

We would find it very usefull. In fact, one of our basic usage senarios involves students working on a report until they feel comfortable with it, and then publishing it. On the other hand, this may also be handled by defining page level access rights.
- YishayMor

See PublishPlugin.

7.05.2003 - Extendable syntax#

Provide an API by which Wiki managers can add their own TextFormattingRules.
This might be just a shell script for invoking a parser.. - YishayMor

See PageFilters.

2.05.2003 - WebLabs requirements#

We're thinking of using JSPWiki for our WebLabs project. There's several features we need wich are missing, so I'll start a separatepage for them. Please edit this page with links to stuff that allready exists, or any insights you might have.

Any change we make, we'll either:

  • contribute back to JSPWiki
  • distrubute as a plugin / overlay.

- YishayMor

21.04.2003 - Add Beanshell functionality to JSPWiki#

I currently have added Beanshell functionality to my private JSPWiki site. Allowing for executing a page in in the beanshell interpreter, setting up a link to execute a page, and using a page/script as a pluggin. If anyone is interested I can clean it up and post it.

Dan Countryman

20.04.2003 - Collapsing / Expanding Left Menu#

My idea is to add code to the jspwiki for using headers within the left menu for generating collapsing/expanding menuitems. This would be usefull for small monitors, people with big screenfonts and a better structure. -- Heinz-Josef Lücking

I just had the same idea too and, stop by here to post it. Seems like it's not a new one. I thought of it as being useful to enable navigation of large set of material (e.g. online textbooks, photo albums). Maybe while editing it, indented text could show that material can be collapsed under the next-higher outdented text. -- MatthewSimpson
: I too thought of some outlining sort of feature, where the left menu, presents an outline view of all the wiki words in use. Check out WikidPad for UI ideas - Akshay..

09.04.2003 - Wiki Macros#

A general facility for macros that expand in-place would be useful. Not the kind we have now - but something that expands immediately and is stored in the expanded form.

I implemented a simple macro that looks like [{now}]. It isnt a plug-in, it expands to the current date/time. This is useful for authors wishing to time-stamp their entry. Here is the code I added to Edit.jsp:

    public String expandDate(String text) {
  Date date = new Date();
  DateFormat df = new SimpleDateFormat("EE dd-MMM-yyyy HH:mm:ss zz");
     text = text.replaceAll("\\[\\{now}]", df.format(date));
  return text;

I also modified the following line...

            wiki.saveText( pagereq,
                           expandDate(wiki.safeGetParameter( request, "text" )),
                           request );


I like the idea of macros, but I don't think they should be "hard-coded" into one of JSPWiki's files. A macro should be something that a user (or wiki administrator) can create without editing the source.

One implementation of the wiki macro concept that I like is the simple replacement of the macro keyword with an pre-defined piece of HTML or JSP code, expanding the macro "in-line", as it were. These code blocks could be stored in a separate directory, like the templates.

The concept is not dissimilar from the way JSPWiki processes embedded HTML, when enabled.

-- PaulDownes, 04/15/2003

This could be done easily with PageFilters while saving a page.

-- JanneJalkanen, 15-Apr-2003

08.04.2003 - Export Wiki Tree as HTML#

Hello, we've been putting our project documentation on our wiki. However, there is some resistance to using the wiki because it's so fluid. By changing over time the wiki makes it difficult to save the programmer documentation in source control or to capture snapshots for versioning. Also, I think there is a fear that maintenance programmers years from now won't know what to do with the wiki documentation. (I'm just kidding, who gives a damn about the maintenance programmers --- Ahhh ha ha ha ha haaaaa!!! -- Oops, that might be me....!!!)

This got me thinking about an export feature that would process a tree of pages and output them as pure, static HTML.

The export feature would probably need to take a depth argument to avoid exporting the entire wiki.

Anyway, the idea would be to export a tree of pages as static HTML where it could be versioned and saved in source control along with other project artifacts.


-- Scott Hurlbert

There is an export feature using the WikiRPCInterface. Actually, someone has already done 90% of the necessary work of what you are after - and MahlenMorris even has a functional implementation of a PrintWiki. See Hula.

-- JanneJalkanen

Hey Scott Hurlbert! JohnV would like to see this particular idea get implemented as a couple of complementary plugins. A PublishPlugin that you insert on a page that publishes plain HTML to a directory periodically (on some schedule) and an ArchivePlugin (that extends the PublishPlugin) that zips up that directory and attaches the zip the page containing the ArchivePlugin. Really cool would be if PublishPlugin extended or used the QueryPlugin to allow publishing of a subset of pages. Thoughts? --JohnV

28.03.2003 - ReplaceTextInPage servlet + Bookmarklet#

When I encounter an interesting link, I store it at the top of a ToRead page. Today, it requires to :

  1. open the ToRead page in a new tab
  2. scroll to end, and click on /Edit/
  3. insert
    * [urlToWatch]
    at the top of the page
  4. click on save
  5. close ToRead page
  6. go back to current page

A discussion list about what's the different between a wiki and a content management system (like www. would be useful
Idea :
1°/ A servlet (jsp) that replaces a string by another string in a given page, and ...

2°/ To automatize the operation, use a javascript Bookmarklet, in a toolbar button, to call the servlet, and pass the 3 parameters:

  in page: ToRead
  replage: * [add-here]
  by: * <current-url>\\* [add-here]

-- Alain Ravet

I don't think you have to do it that difficult. You could probably rip off Edit.jsp and make a simple JSP page that would append the interesting link on top of an existing page. --JanneJalkanen

26.03.2003 - Modification to PageContent.jsp#

I would like to suggest the following revision of PageContent.jsp:

<top link removed>
Good idea. It's now in 2.1.2. --JanneJalkanen

While adding this entry, I noticed that the presentation of a code (preformatted text) block does not display "& nbsp;" and similar chars, although they show in the Edit window. Would it be desirable to display them?

-- PaulDownes

Err. Ngh. Too tired to think about this. Will come back to the subject =). --JanneJalkanen

22.03.2003 -- Optional parameter for opening links within a new window#

I would find an optional parameter within [links] useful special for external links. This parameter could e.g. look like [link:new].

Another idea is opening general all external sites, that do'nt belong to the internal wiki, by a parameter set in the

--Heinz-Josef Lücking

Yeah that would be great -- Krzys

I personally find the new browser windows extremely irritating - if I wanted a new window, I would specifically request for it... But then again, I've been spoiled by Mozilla's tabbed browsing.

The problem runs deeper than adding a new way of linking. We really need a way to define the link format exactly instead of adding new extensions to the WikiMarkup. I am not even sure that it is the site maintainer's responsibility to decide which links warrant a new window and which do not.

-- JanneJalkanen

I wish to chime in here. I also really hate web sites that keep causing new windows to open. If I want a new window, I will use the right-botton menu option for 'open in new window'. I personally really like the way the whole wiki and all referenced pages run in a single browser window. If an option exists causing new windows to pop up, I would encourage wiki owners to not use it. -- KeithSwenson

It is possible to open links in a new Browser-Window, see JSPWikiFAQ -- KarlHeesch

-- I Think every [http//...] external Link should generall be open in a new browser window, cause this link is not related to the wiki-contents. the wiki will still be an open window then.

14.03.2003 -- Robots Plugin / Tool for Admins
--Heinz-Josef Lücking

Would'nt it be a good idea to use the content/code of the index for generating a starting index.html (or default.htm etc...) as a starting file for the/a wiki too make the content of a wiki available to search engines. This file could redirect the users to the "real" wiki.

I don't understand what you mean. Wiki content is available to search engines: try searching Google for JSPWiki, and you'll see that we're listed there. --JanneJalkanen

As far as I know search engines do'nt look within scripts etc. E.g I can't find entries within google on giswiki. Could it be a problem on ---Heinz-Josef Lücking

Yes, they do. In fact, this Wiki changes so often, that Google is a regular visitor over here (it does something like 10% or more of our page accesses...)

So true : when I google my name, THIS site is the first of 2200+ results. --Alain Ravet

It could be that Google has not found you yet (look at the server logs); or that you have robots.txt that prevents Google from indexing your files. Or you have some other problems with your setup. Could be dyndns, or the fact that it is in port 8080 for all I know. But it is very unlikely that JSPWiki is at fault.

-- Janne Jalkanen

I've got the wiki working only with port 8080. Does anybody know how to get it work without port 8080

-- Heinz-Josef Lücking

Depends totally on your servlet container. In Tomcat, look for the string "8080" inside server.xml. Others, can't really help...

-- JanneJalkanen

14.03.2003 -- Hit Counter as a JSP-Plugin
--Heinz-Josef Lücking

How can i insert a hit-counter in a wiki?

Use any available hitcounter and put it in your JSPWikiTemplate. --JanneJalkanen

Does anybody know an available hitcounter? --Heinz-Josef Lücking

The PageViewCountPlugin maybe you can use:)-- Luke Han

March 13, 2003 Change Summary#

It would be nice to have a "Change Summary" or "Reason for Change" text field (small field, not a text area) on the edit pages for a short description of what/why you made an edit to the page. For example, I would enter "Change Summary Suggestion/Request" for this one. This information could be stored in the file (say, as an "n.summary" key?) which could then be presented in the recent changes, etc. It would also be used during a search. Of course, I also think the recent changes page should show you the summaries for multiple changes to a single page made on the same date, too, but that's another issue ...



Well, the change comment is something that has been on the back burner for a while. However, the "show multiple changes on RecentChanges instead of the last one" was something that was hashed through in the very beginning of JSPWiki, and we decided it is better to keep it compact. However, it might be better to add a "show me the difference to the last 24 hours"-kind of functionality.

-- JanneJalkanen

March 7, 2003 - 3 ideas: a new "edit link"; a "print" button; upper-left sign-in#

These are three simple layout customizations, two of which I've done locally, and really like. (Yes: they're trivial).

The first is to put another "edit this page" link directly below the "find" button (and to the right of breadcrumbs). Many pages end up being organized with the most relevant/new information at the top of the page; having the edit button here helps people figure out what to do.

The second is to move the "G'day user"/Sign-in message so that it's directly below the upper-left "JSPWiki" link. When I did this, I made the "please sign in" link

blink in obnoxious red... maybe that's too much, but I (locally) wanted to encourage people to identify themselves...

The third idea (I haven't yet implemented) is to put a "print" button (meaning "relayout

for printing") in the upper-right (next to the new "edit" button I suggested above). This would simply relayout the page without the LeftMenu, without the "edit" links, without the "search" box for printing. I am aware of XMLRPC printing extensions that have been worked on; I just think it would be convenient to have something directly available.

-- CraigRobertson

The first two modifications are something that purely depend on taste - everyone is free to modify their templates as they wish.

The "print mode" is something that quite a lot of people have suggested, or made workarounds to, so I guess it is something that should be added to the default template as well. I think this could be done easily with CSS (and probably should be done, too) :-).

-- JanneJalkanen

March 5, 2003 - preventing Wiki Links for a page?#

Is there some way to disable CamelCase Wiki links on the page level? I have a few pages where I write about java classes extensively, and all the wiki links really clutter things up. I would still like to use CamelCase for the rest of the wiki. --KenLiu

Use CamelCase (that is, prefix the word with a ~). Sorry, no page-only preferences. Though it might be a nice idea.

-- JanneJalkanen

This feature is available since v2.1.21.

05/03/2003 - Markup rendering API#

We thought about a standard API between wikis and its rendering part. This would make rendering engines exchangeable (regex based, parser based, speed optimized, ...). We refactored our SnipSnap along this API. The outsourced wiki rendering engine is called Radeox.


I think Ideas - TranslatorReaderEvolution is the correct page for this :-). --JanneJalkanen

14/02/2003 - Category Pages#

Category pages should be automatically created pages (meta-pages?), like the Search page.

The user types a new category name, e.g.


When the ? is clicked, the page is automatically created with content such as:

__Pages in this category:__




Note the CategoryCategory category (say that fast 3 times).

This would be another meta-page which automatically lists all pages that start with "Category".

-- PaulDownes

Naaah, not much benefit to this, besides saving yourself a tiny bit of work to create the Category page. If you don't even persist the page, then it's not really any different than a search, is it? --KenLiu

And you would have to link to the Category page anyway manually... I can't imagine a situation where you have so many categories that their automatical creation lessens the burden in any significant manner. --JanneJalkanen

CVS-to-RSS feed?#

This is not exactly a JSPWiki idea, but wouldn't it be interesting to be able to subscribe to JSPWiki CVS commits directly using an RSS feed? More discussion at CVS to RSS Feed.

--JanneJalkanen, 06-Feb-2003

2-Feb-2002 : icons for bullet#

Suggestion : an extension to the bullet syntax
* a/ default bullet

*:[Pic/blueDot.png] b/ use the blueDot icon as bullet symbol
*:1 c/ use icon #1 as bullet symbol
*:0 d/ use default as bullet symbol

Result : something like .. (correct alignment and spacing )

  • a/ default bullet Pic/blueDot.png b/ use the blueDot icon as bullet symbol
    Pic/blueDot.png c/ use icon #| as bullet symbol
  • d/ use default as bullet symbol

28-Jan-2003 create "official" JSPWiki documentation#

I recently read a review of JSPWiki on another web site (don't remember where) and it was favorable overall, except that it said that JSPWiki lacks documentation. I know the Wiki itself is a form of documentation, but I think it is lacking in structure.

The problem with the current wiki documentation is that is that many things aren't clearly documented or are documented in more than one place. It's not easy to read through in a comprehensive and linear fashion without surfing through the entire wiki. I think it is important that we keep such documentation separate from discussion. The way things currently are, it's hard to tell the difference between features in CVS and released functionality.

I propose that we create an "official" set of documentation that is kept up to date. Since no one likes being responible for writing all of the documentation, perhaps we can keep using the wiki, but mark each "official" page with "CategoryOfficialDocumentation" at the bottom of the page.

Then we can create a documentation Table of Contents page which links to all of these "Official" pages. By doing this we can also see where the gaps are. Perhaps all these pages could then be extracted from the online wiki and included as a seed wiki instance in the release distribution.

Of course we could go the static HTML page documentation route, but I think this is less contribution-friendly. -KenLiu

I agree with this sentiment. The JSPWiki documentation is a bit of a mess right now, and we should probably start a new WikiCategory for that purpose. (I don't think we've done too much categories yet - perhaps it's time to start using them). I added a suitable starting point to the LeftMenu.


From today on, there is now an CategoryOfficialDocumentation. Everyone is free to contribute! --JanneJalkanen, 30-May-2003

2003 Jan 02 - Calendar features#

I love the CalendarTag. (For those wondering what I'm talking about, take a look at Janne's blog.) What's its status? I'd like to see some switchable features:

  • move to previous/next month, and year
  • (optionally enabled) click on a day to invoke Edit.jsp with that day's entry

I'll volunteer to code these in, if they make sense and Janne's swamped.


I made some additional changes to it in 2.0.25. There is still no ability to move forward and back, because I ran out of phlogiston while writing the code. I wouldn't mind a patch or two. I basically upgrade it as-needed on my own weblog. I was planning to add at least the ability to go back and forth in months to it, but I had no bigger plans.

Incidentally, you might want to integrate it with the RecentChangesPlugin the same way it now integrates with WeblogPlugin, i.e. make RecentChangesPlugin understand a "recentchanges.startDate" HTTP parameter.


21-Jan-2003: "add a comment"-style editing#

copied from another page:

JeremyC: I agree a mailing list would be more comfortable on discussion, but what would be cool is if you could create a Wiki page, then have a comments entry form. It could simply just append a - - - -, the comment then a -- [Signature] to the already existant Wiki page. Oh, a date as well. That would make discussion and general use for some types of Wiki's pretty slick.

Basically this follows comment interface seen in blogs. There are lots of pages on this site (like this one!) where people append/prepend comments to the page. This would make this easy to do, and would also pave the way to blog-like usage of the wiki. It would be easy to create an alternate edit jsp for this, not sure how to integrate it though. --KenLiu

Yup. A separate "Comment.jsp" should work fine - it would work both with container-based authentication (allow people only to comment, not edit), and a more fine-grained authentication (we just need a comment permission).

I've been thinking about it especially in conjunction with my own weblog.


Jan 13, 2003 -- KenLiu MostActive and MostPopular pages#

Is there a way to view a list of most active (most frequently changed) and most popular (most frequently accessed) pages?

No. JSPWiki does not log that information (though it would be relatively trivial, but there are some persistence problems). We have Analog set up for statistics.


Please expound on the persistence problems you are thinking of.


We would need to log stuff on disk using some sort of asynchronous scheme, and then the statistics would need to read that file. I fear it might be a bit too slow. Caching in memory is not an option, methinks; that brings on persistence problems (upon container restart, for example), and we have better uses for that memory.

It currently takes roughly 20-30 seconds to calculate the current statistics.


Jan 3, 2002 : watch url's last_modified value, and signal/display icon when new version available.#

I keep hundreds of interesting links/urls in my wiki.
Being able to find them later, is my goal #1.
I miss the ability to see in a glance when they have changed. As I keep them because I find them interesting, knowing that their contents has changed is also very interesting.
A great new feature would be to see a little icon, next to the link, when the target page has changed.

Example :

  • links to external blogs, news, ..
  • link to ChangeLog,
  • ...

Hm. Might be a bit of work. Also, it would be difficult to cache the information persistently over restarts of the servlet container. Though you could make an enhanced plugin for that ([{Link url='http://..'}]) pretty easily. You could also put in plenty of other functionalities in there. Perhaps someone would like to take up the exercise? --JanneJalkanen.

It's very difficult to determine whether an arbitrary page has changed. Since (most) web sites are so dynamic, you really have no easy way of determining whether the content has changed without some kind of semantic markup on the target page (where is the content?). It would be a nice feature to have, though. -KenLiu

Of course, one could watch for the "Last-Modified" header, and hope that it would be correct :-). --JanneJalkanen

30 Dec. 2002 -- per page stylesheet#

I need to include in my wiki simple pages with a distinct and common look, a little like this.

JSPWiki would be the ideal way to produce and maintain them : simple text editing, with a simple format. This feature would give JSPWiki contents a more professional look, and make it gain new users, while keeping its most attractive qualities : easyness and simplicity. I'm convinced this would add tremendous value to JSPWiki, and push it in another league.

It only requires :

  • per page, stylesheet (kind of attachment)


As for per-page stylesheets, the solution that immediately springs into mind is to have a [{STYLESHEET pagespecific.css}] directive on a page. Though, this would need us to rethink some of the parsing thing - collecting references and other stuff should probably be done in a cleaner way than what the current TranslatorReader architecture allows us.


Available since v2.1.21, though only on a per-template-basis. But you can rather easily extend this to skins as well.

12 Dec, Ability to directly attach files from websites#

Why not? It would be a nice shortcut. It saves the "download temporarily to local", and "delete temp. from local" steps. When creating a page about a product with a site, I like illustrating it with a logo, from their site. This is why I tried the url thing.

--AlainRavet, Dec 12, 2002.

You shouldn't be able to do it because there is no code for it in the current JSPWiki base :-). As for whether the code should be written... Well, I am not certain. It sort of feels like a good idea, but it would make inadvertent copyright violations possible - not everyone realizes the difference between linking and copying. The other thing is that writing the code for that might be a bit hairy - I don't know how much you would need to get into the HTTP spec to be able to do that properly.


Actually implementing this shouldn't be that much of a problem. It's rather a limitation of multipartrequest.jar. If you look at the data sent when you enter a file or a URL, it's not that different:


Content-Disposition: form-data; name="content"; 
Content-Type: application/octet-stream



Content-Disposition: form-data; name="content"; filename="test.txt"
Content-Type: text/plain



btw, I think the WebLog feature would be great for this page, if there would be a comment-function.

-- Torsten, 2003-01-05

November 20th, 2002 -- JeremyC#

Page Rename#

In the editor, it would be cool to be able to rename a page and have it update all the associated links. I suppose that this could be done with a shell script and sed, but the average end user wouldn't be able to do it.


Shell scripts and sed are not too portable across platforms, I'm afraid... Also, then you would need to have automatic recognition of links. However, we already do know all of the referring pages, so it would not be impossible to do this - it would just mean writing a somewhat brittle piece of code. Volunteers?

--JanneJalkanen, 22-Nov-2002.

See RenamePagePatch for a workaround.

Development of the JSPWiki#

I would like to help developing this JSPWiki, but find it a bit tricky, where to start and what to do. This is caused by the following issues:

  • It is very difficult to figure out what is currently being implemented by other developers.
  • It is difficult to navigate these pages for ideas since there is several places where ideas are placed (Ideas, Starting points).

A few ideas:

  • Make it possible to contribute directly to a cvs repository.
    • JanneJalkanen: No. Patches are accepted via email, but no, I will not start giving access to the CVS repository unless I know the person very well. The potential damage is far too great.
  • Make 1 place where ideas are contributed. These ideas must then be followed by a discussion, documentation and implementation. All in one place.
    • This could be implemented by making a page, where these new ideas can be added as links to a seperate page. This page must then contain the description of the idea, and a discussion. If the idea is implemented, the patch must be linked from that "idea"-page. So everything from idea to patch is in 1 place.
    • JanneJalkanen: Feel free to make such a page if you have a good idea - this is a Wiki, after all :-). Seriously, if you have a good idea how these pages should be reorganized, go ahead and do so. If it's generally disliked, then someone will change it back :-). Note, however, that in great many cases the discussion dies off quite quickly, and that people in general like to just drop ideas off on a single page - very few people like to create new pages, simply because it requires an extra step.

Text Rewrite?#

Sept 11, 2002 xfer

How about a text rewrite plugin, to change all ":)" to a graphical smile?

  • What I have wanted is a plugin that would be able to read in the whole page and act as a filter for the page. And changing :) to a graphical smile is not what I needed, but it could do the trick. NiiloNeuvo
  • Let's take this to PageFilters. --JanneJalkanen

printer friendly mode#

Sept 2, 2002 AlainRavet

To hide the left column before printing, I created a WikiPrint.jsp and a ViewTemplatePrint.jsp alternative. Problem: each new click reactivates Wiki.jsp.
A new request parameter, triggered from Wiki.jsp, could handle this much better. The /Search/ field, as well as the /Edit/ and /More info/ links could be hidden as well.

  • Has anyone written yet a 1.9.x template or stylesheet that you could use for the same purpose? --JanneJalkanen

Multiple domains, à la TWiki.#

30 August 2002 AlainRavet

Advantage : when using JSPWiki to track projects, you can separate them.
Impact on :

/me nods. Possible, but not in the main priority list right now. Suggest that you use a separate JSPWiki instance for different projects. --JanneJalkanen

AlainRavet: The lazy XP man in me wants to suggest a stupidly simple

notation, like [Main.Page1].

Yes, either that or "domainName/pageName". We originally allowed "." in WikiNames because we wanted to allow people to create pages for their computers in intranets, such as []. Currently, slashes are disallowed and removed from WikiNames. --JanneJalkanen

AlainRavet : If there was a page_name_pattern field in the search procedure, we could ask for :

  • Search for "gui" in the "*java*" pages
  • Search for "java" in the "*test*" pages.
but also :
  • Search for "something" in the "Project1.*" domain

StevenNoels: just stating my support for this multiple site/single instance wish, since I'm hosting quite a few JSPWiki instances right now, some of them who could as well be collapsed in a single instance. My main problems are tracking versions of the engine, templates, and my howebrewn (in progress) Python recentchanges2emaildiffs app.

29 August 2002 ebu#

JSPWiki management tools, Current Users functionality#

What kind of wiki management tools would we like to see? Currently management is pretty trivial: organize and refactor, occasionally remove a page or two. If/when attachments, user authentication and access restrictions come in, JSPWiki admins immediately have a lot more to adjust. Here's a list of things I'd like to see:

  • Current users logged in (requires authentication, first)
  • User (and group?) management (WikiPage? See recent additions to JSPWiki authentication)
  • Access control (WikiTags? See JSPWiki access control)
    • specialized search tools to find controlled areas/pages?

16 August 2002 MahlenMorris#

Dual Wikis on the Same Files.#

This is not so much a feature request as just a goofball idea. Is there any problem with running two different instances of Wiki on the same server, pointing to the same directory for storage? I'm thinking it'd be nice to have one that is editable that has the normal Wiki look, and another that i can use for display only purposes. This is one way to get around the "all links are to Wiki.jsp" problem.

This would be especially nice for my company's Wiki, as the read-only wiki could be customized to display it nicer for presentations (I always have to tell the audience, "Ignore the stuff on the left").

Janne, any reason why this wouldn't work? I guess you wouldn't want the read-only wiki to use caching, and they'd need the same base FileProvider Type. Has anyone tried this?

JanneJalkanen: I can imagine interesting issues with concurrency... However, if one only does reading only, then that should probably be okay. However, you should not enable CachingProvider with the read-only Wiki, since it is not smart enough to notice when a page has changed on disk. You can, however, enable all bells-n-whistles on the writable Wiki.

You might also want to consider using just plain FileSystemProvider for the read-only Wiki, since it's compatible with RCSFileProvider and VersioningFileProvider, and then you wouldn't have to worry about running RCS concurrently (like doing Page Info at the same time as someone is checking in stuff. I have no idea whether RCS can handle that sort of stuff.)

MahlenMorris: Actually, I think I've found a better solution to my read-only view problem. Just make a page called Wiki.jsp in some directory other than the main Wiki directory. You can then modify the new Wiki.jsp anyway you like, and any Wiki pages it links to correctly link to that same Wiki.jsp. This works because the code that generates the links is copying the full directory path from the calling page.

JanneJalkanen: This is true as long as you don't set the jspwiki.baseURL property in the file. But otherwise it should work, yes.

Page keywords & search engine#

I'd like a way to associate keywords to a page, kind of

 keywords:  web, test, testing

Currently - 1.9.13 - you could enter it as free text, but the search engine doesn't give them a higher priority, because it doesn't understand the notion of keywords.

I have the feeling allowing xml formatted text into page contents would ease further development and extension. They could be seen as page properties, with proper API support.

 <keyword hide="yes">:  web, test, testing<keyword/>
 <jspwiki:keyword hide="yes">:  web, test, testing<jspwiki:keyword/>

--Alain Ravet

Hm. I like this idea - there really should be a way to mark a line as keywords.


I agree, I too like the idea. I tried just adding some text to my pages, but didn't like the fact that the keywords show on the page. I have RAWHTML turned on (true). The suggestion above ignores the tags and shows the keywords which gets us halfway there, but I wanted to be able to tag the pages without viewers seeing my keywords. (In this case, I've posted pictures and I'd like to be able to keyword the names of the people and the places but I don't want this info to clutter the page.)

What I decided to do was add the keywords as HTML comments. I added:

<!-- Keywords Scott Domino -->

This works great and you can do a search with "+Keywords +Domino" and you'll get only the pages keyworded for Domino (in this case, the name of my dog).

What do you think? -- Scott

22 July 2002 MikeWhite#

How about Connection Log? The log file seems to already log it; but I was thinking on a page all by itself. Might be a better thing if it was offered as a JSPWiki plug in.

JanneJalkanen: Why not? It should be easy to write a custom log4j logger for it.

June 28th, 2002 DuncanMcGregor#

Preview Tooltips#

JavaDoc takes the first sentence of a 'page' as its summary. How about pulling these first lines into the reference manager cache, and using them to tool-tip the Wiki names. It would save much following of blind-alleys, and allow much nicer annotation of pages without spoiling their flow.

JanneJalkanen: Brilliant idea. Will do!

GamesBook: Will this feature also be added to the search results - so that, like other search engines, you get the page name AND the first (or embedded?) sentence.

JanneJalkanen: Well, at least that... In truth I'd like to see a few words around any hit that the search returns, much like Google or other search engines.

June 28th, 2002 DuncanMcGregor#

Don't Automatically Edit#

If you click on a Wikiname which doesn't exist, c2 wiki takes you to this page doesn't exist, not edit. Going straight to edit is a bit intimidating - could we set that as an option?

JanneJalkanen: Well, it sort of does. The question mark is supposed to signify that the page does not exist, as opposed to an underlined link that will take you to an existing page. This is done in the interest of lowering the threshold to create new pages as easy as possible. If it's intimidating, should we then have a nice, friendly explanation on the editor page that you're creating a new page?

DuncanMcGregor: I don't think that's any substitute for not editing when your site (well, ok, actually my site) is used primarily as a read-only resource by sometimes novice users. Its a shame if I don't mark SomeThingToComeBackTo, but then just plain frightening if someone clicks on it and finds themselves in this horrible pink form thing. One thing I've learned from the site, my readers don't read any more than the first paragraph of anything.

Sorry this reply took so long - the original got lost in a freak IE preview loss (they seem to happen quite often - preview, shift-click to check a link in a new window, back in the original window, and the edit is lost). I'm happy to write the code for deliberate editing if you can point me in the right direction.

IE preview losses should've been fixed in 2.0.21, methinks. --JanneJalkanen

May 15, 2002 -- MattMower#

Refactoring indicator#

I was pondering whether it would be possible to come up with some simple metrics for analyzing text in a page that would determine whether (and possibly how much) a page required refactoring.

As a trivial (and I bet easy to shoot down) example: You might look at how many sections delimited by -- markers there are and say >5 means the page should be refactored, >10 means the page desperately needs refactoring etc..

JanneJalkanen: It actually works out pretty well if you just mark the page to be refactored. For example, write Please [RefactorMe] at the end of the page, and then it's real easy to go to a page called "RefactorMe" and see which pages point to it. Someone will then either refactor that page or remove your refactoring comment, if he doesn't think that that is necessary. This is WikiCommunity hard at work :-).

MattMower : That's a good idea.

ebu: So... do I refactor this page, or not? ;) (My take: no; a bunch of ideas sort of belong together. Yes; it's a bit difficult to find changed information from the middle of a page. Which reminds me - see [1])

May 3, 2002 -- MattMower#

DHTML Menus#

I quite like the banner menu's used by some other Wiki sites. I think they should be augmented by using DHTML menu's to keep the ammount of screen space used to be small.

JanneJalkanen: Nope. DHTML does not work cross-platform. CSS could be used for this, though.

That would be a great addon


May 6, 2002 -- MattMower#

Home page#

I would like a way of registering that I am interested in a page and having another page that collects together all those pages in which I have expressed an interest. It should display them in modification order with the date of last modification and the delta information. As a Wiki grows this will allow me to easily see the changes to only those parts I am interested in.

Also having grazed RSS on this Wiki I also wonder if it has a role to play? Maybe it would provide the facility to create a page (hosted on one RSS compatible Wiki) that collects together the changes you are interested in across a broad collection of Wiki's that support it?

MahlenMorris: Regarding your first suggestion, you might want to look at two of the Hula apps I've written:

  • The first is the EmailGenerator, which sends emails every 24 hours of delta information when pages you've picked change.
  • The second is the less-fleshed-out PrintWiki application which amalgamates pages together into a single HTML page (you can try this on this JSPWiki at Since the produced link is unique for a set of pages, you can save it on your browser bookmarks or even to your MattMower page. Currently the pages are in alpha order, but it could alternatively be in 'recently changed' order, I suppose.

Matt, do either of these usefully address what you want?

JanneJalkanen: I don't think a generic RSS aggregator plugin would be that hard to do. You'd probably want to implement it with a simple cache, though. Filtering out only specific pages wouldn't be very difficult either, so... If someone wrote this plugin, it would be very cool (hint, hint, nudge, nudge). :-)

For other pages (hopefully non obsolate) related to submitted ideas, see also Category Ideas.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-676) was last changed on 10-Jun-2012 10:43 by Janne Jalkanen