For example, the LeftMenu, BottomArea etc. are current editable topics - some wikis encourage collaboration on the user interface design but these are especially fragile pages. Everyone should be able to fix an error or unnecessary dead or open link but their fix -the latest version - might be best held for someone else to approve of, say make a null edit so that for those pages only the most recent version created by an editor with permission to change the user interface will be used to actually generate the framing on each page.

imported pages

It may be desirable to include content from mailing lists and other sources, in which case that content should be read-only (changes to someone's original email would be wrong and confusing, though most wikis manage this socially and have few or no problems with attempts to screw up attribution and so on.

Wikinfo deals with this well: It imports Wikipedia pages but it allows them to be viewed and edited as if they were local, creating a new Wikinfo page. Warnings and headers on the Wikipedia imported page explain the options that the user has: edit at Wikipedia using it's editorial process, or edit at Wikinfo and create a new page from Wikinfo's POV.

moderators or senior editors

Another useful user group ("moderator" or "senior editor" or similar) could have rights to make topics read only, and other types of low-impact admin tasks, but unable to do proper admin tasks (e.g. can't access admin pages).

Jabber support

The jabber ID is in use now as a universal single login for multiple wikis. Wikimedia proposed using it as it is a far more distributed and already-implemented infrastructure than OpenID, with none of OpenID's many problems (most notably the way OpenID is biased towards identifying everything with a person's body or "real name" rather than merely a persistent account name). It should be implemented before OpenID because there will be far less resistance to it, and because jabber clients also support all the chat networks.

OpenID Support

OpenID provides a way of logging into multiple web sites. It would be nice if there was a UserHandler for JAMWiki that provided OpenID support.

this might soon come for free (or close to it) thanks to acegi openid support

Forgotten passwords

Implement the capability to email a new password when a user clicks on a "forgot password" link. See also ForgottenPassword.

Hardwired reputation system

See http://www.firstmonday.org/issues/issue11_9/cross/index.html for a discussion of some issues. In order to better handle vandalism it might be nice if there was some way to recognize reputable editors and then give an idea when viewing changes and history as to how reputable an edit actually is. This system could probably be enhanced by using spam filters, edit patterns (see http://en.wikipedia.org/wiki/User:Tawkerbot2), etc.

See also http://www.firstmonday.org/issues/issue8_8/jordan/ for a discussion about Augmented Social Networks -- Jack 07-Mar-2007 15:01 PST

no reputations not encapsulated by (social) factions - a contrary position

Any definition of "reputable" is wrong or at best controversial. While it's a very sound idea to ORDER PRIORITIES of administrative actions based on some metric that an administrator chooses to trust, that can't be one imposed by the system, so to work it has to be very customizable. It has to be social and dealt with as part of a suite of social features like friends and etc..

The least controversial thing to do is encapsulate the "reputation" system so a "faction" of users agrees to use and maintain it. The default could be that all administrators form one faction, but anyone could form a new faction and adjust the parameters of the system or simply hand-undo the way people or IPs have been labelled. In any case the system itself must not impose one way of assessing "reputation" or, sure as slashdot, it'll be gamed as a moral obligation by all those people who object to such systems on principle. That's far less likely if the whole thing is properly labelled as merely one faction's choice of how to set its own internal priorities.

In especially contentious wikis or those with a real need to express fairness, the factions could compete as parties do in elections to set the dominant mode of reputation.

Anything less is an administrative power grab, so no "reputation" system should be implemented until it's very clear that subscribing to a reputation system is voluntary and that any group of users can set up their own independent of that which the administrators prefer.

Ten minutes on Slashdot and you can see exactly what's wrong with having one monolithic "reputation system" - insightful posts by strangers sit at zero as crap authored by trolls gets modded up to +5 by each other as sort of a game. Administrators are just old trolls - they'll censor those who they don't understand or like, and drive everyone else off, if they can. Wikis just don't work if users rank and rate each other rather than the pages, and they won't work also if pages disappear just because someone unknown wrote them.

Social features - networks, notifications, messaging and peer-run ratings

New message notification

Add an icon next to the "User comments" link in the user menu to indicate that a new message has been added to a user's talk page, similar to what is done on Wikitravel.

Ideally, send the message itself to a chat network, possibly one tied to the email registered. It really is not difficult to find an MSN or Yahoo or jabber account matched to that email, or to ask for it up front when registering. If the user who left the message also has such an account, jamwiki could even set up the two in a chat to talk to each other live.

Email Support

JAMWiki will eventually need to be able to send email in order to support registration confirmation, "email this user" functionality, forgotten password functionality, etc. There is code in the codebase currently to support sending email, but it is untested, orphaned, and un-reviewed. Tech:Email

Mailing List Integration

Create tools to do things such as integrating with mailing lists. It is difficult to follow the discussion on a mailing list due to a lack of context, so it would be nice to allow a Wiki interface to follow those sorts of discussions. Add a message on the Wiki should (optionally) send a message to the mailing list.

RSS

The old Very Quick Wiki code had RSS support, but it was unmaintained after the JAMWiki fork and has been removed. Re-implementing RSS should be a relatively simple matter, although it would be best to match Mediawiki's format when it is done.

I've done some work on this - see Tech:RSS -- Rainer 22-Dec-2006 11:23 PST

social networking integration (OpenSocial API, user page templates)

Wiki user pages are actually much more functional than typical social network applications like Facebook or MySpace, since they can be arranged arbitrarily and users can develop their own conventions to signal things (for instance the way Wikipedia users explain their expertise and language mastery to each other with tags on the pages) to each other without having to be programmers.

Also, wikis do a far better job of letting someone track individual topics of interest (rather than "groups" which tend to be larger grained), and letting others review your contributions to find points of common interest.

However, creating such user pages requires more work than say Facebook pages which typically can be created by agreeing to a few things with single clicks. Some user page templates need to be built in to make it easy to make a Facebook-like or Wikipedia-like profile with whatever tags seem relevant to that wiki.

Until now also there was no standard way for developers to extend the social functions, for instance, introducing people based on common interests as signalled in watchlists (without revealing necessarily what those are) or contributions. But now there is, the OpenSocial API. Using that, "developers can create applications, using standard JavaScript and HTML, that run on social websites that have implemented the OpenSocial APIs. These websites, known as OpenSocial containers, allow developers to access their social information; in return they receive a large suite of applications for their users. The OpenSocial APIs expose methods for accessing information about people, their friends, and their data, within the context of a container."

So if JAMWiki user page templates report the social information to code that publishes it via the OpenSocial API, every jamwiki web site becomes such a container. This works especially well with a single login and blogs since signing pages in other wikis can trace back easily to the profile that includes the most social information. This in turn would prove especially useful for resolving disputes - you might find it really easy to find mutual friends who could moderate the discussion on some controversial or inflamed topic. This could even be automatically invoked on say violations of the 3RR.

Factional reputations

The hardwired reputation system can be easily replaced once social networking and OpenSocial are supported - just use the typical filter sharing and heavily friends based recommendations and ratings systems typical of social networks, rather than a gameable horror which only slashdot trolls will love.

3RR

Detecting whether the same version has been restored three times (or some other number set by the system) could be built in and trigger a log. While there are legitimate reasons to do this, like wiki spam and wiki vandalism, generally other solutions such as captcha and block IP should be used for repeated offenses. The 3RR exists for human disputes and the system could help resolve them with a 3RR log and, in conjunction with the social features possible with OpenSocial, find a mediator.

This is a notification/messaging concern because the system itself should not set hard policies about inter-user disputes.

Blog

I'd like my wiki engine to be a blog engine as well. Maybe, each user could have a Special:Blog page. The n latest entry would be displayed there. Writing an entry should allow wiki syntax with links to real pages, obviously. And trackback must be supported. Ideally, the API of a major blog engine should be implemented in order to allow web site integration. -- Régis Décamps

Have a look at Axel's project Bliki. The goal is to create a Wiki-based blog, and it supports JAMWiki. -- Ryan 13-Oct-2006 16:30 PDT

You can test the Plog4U Wikipedia Formatter in this Groovy-News Roller instance. If you define a template _wiki you can define your prefered default wiki instance. In my blog I defined for example the english wikipedia as the default with the following template definition:

wiki_url=http://en.wikipedia.org/wiki/${title}
image_url=http://www.groovy-news.org/e/axelclk/${image}

Additionally you can use interwiki prefixes. For example the interwiki prefix jamwiki links to jamwiki.org. See the test blog http://www.groovy-news.org/e/page/test for some other examples. -- Axel Kramer

blogs aren't compatible with wiki interfaces - contrary position

Not that anybody asked me, but ... I don't think building blog functionality into a wiki is the right way to go. They are fundamentally different in purpose. Blog is a publishing tool for non-editable content. Wiki is a collaborative editing tool. I think it's fine to have sister projects that are compatible, but I would not recommend combining them into one piece of software. -- scroco 13-Oct-2006 16:47 PDT

I agree that JAMWiki shouldn't force a blog engine onto users, and I don't plan on ever integrating a blog engine directly into JAMWiki. However, if people are interested in using JAMWiki as a base to build a blog engine (or anything else) I'd like to work with them to make it possible for them to do so, either via an extension mechanism or some other method. Having projects out there that are using the JAMWiki code provides a great opportunity to gather feedback about how to extend JAMWiki functionality, and in the long run should be helpful for developing methods and APIs for extensions and inter-operability. Long-winded response, but just wanted to clarify that JAMWiki won't become a blog engine, but that I'm very much in favor of having "sister" or "child" projects out there trying to extend JAMWiki functionality, and I'd like to be very open to feedback from those projects about how to improve integration with JAMWiki. -- Ryan 13-Oct-2006 17:23 PDT

I'd like to see an extension to add blog functionality to JAMWiki, too. I used many Wikis and occasionally I want to add blog entries. I like the freedom of Wikis to design my entries with wiki syntax and arrange them howsoever I like. But the software could support me, especially with overview pages and tagging :-) Mike 21-Jul-2007 18:46 PDT

a "publish" tab and "subscribe" mechanism

Another option would be to put a "publish" tab on every page, similar to the page history, which shows only those versions that a given faction or group of users has chosen to "publish" as their approved version. This capability, minus the democratic ability to have multiple such factions, was discussed extensively as a "sifter" or "official Wikipedia" back in 2003 or so by Larry Sanger (in Sanger's version, he himself would lead the only faction able to make publishing choices, but there's no inherent reason for this exclusivity).

Then the "blog" interface consists of the published version and all comments on any published version by any faction that one "subscribes" to (say via RSS). If one subscribes to the published version one sees only publications by some faction, not all edits by everyone. It would be clear which version a comment was attached to (which is very UNCLEAR in wiki talk pages) but all comments would be visible at once with the latest version, and it would be easy to look at the earlier published versions. Looking at the entire page history would be possible but not mandatory. This would make it easy for private wikis to publish to public websites.

user interface

Clean up inconsistent EN language translation

"StartingPoints" is a WikiWord beside "Recent Changes" which isn't consistent with the mediawiki "Special:Recentchanges", and while "Special:Specialpages" is, "Special Pages" isn't. This is a mess and it's very easy to fix:

• Remove all capital letters after the first character as mediawiki does - remove all WikiWords from the interface everywhere, i.e. StartingPoints should become "project:entry_pages" or something which is more consistent usage of "pages", and clearly designated within the project name space only, so multiple projects could be accomodated on the same base of pages in one wiki.
• Support the mediawiki capitalization precedents on Special:Recentchanges and Special:Specialpages and so on - note that special:recentchanges and special:specialpages are treated identically by mediawiki but not jamwiki as of 0.6.3
• eliminate extraneous capitals, i.e. "SourceForge page" is fine, "Page" is not
• absolutely eliminate all capital letters from the user interface by default, i.e. "Edit Comment" becomes "edit comment" or better, "edit summary" exactly as mediawiki calls it
  • Toggling between a proper-english no-capitals-except-on-proper-names and the existing crap is also an option, but the latter seems to have no advantage. It's inconsistent with mediawiki and with itself, and should go.

Someone care to fix the EN translation?

Rename Default Virtual Wiki

Allow the ability to rename the default virtual wiki "en" to something else.

Enhanced diff

Currently the JAMWiki diff code highlights lines that have changed. However, if only a word or two within that line changed it can be difficult to see what actually was modified. Mediawiki adds additional syntax highlighting to the portions of a line that changed, and it should be possible to do the same with JAMWiki by first finding lines that have changed, and then diffing the two lines to find letters and words that have changed. This functionality isn't difficult to implement, but it IS difficult to do in a way that keeps the code readable and maintains a separation between presentation and processing logic.

Export to PDF/HTML/ODT/DOC/Other

Wikis are a valuable tool for design since they allow users to collaborate to work out design details. Once something is "complete" there should be a way of exporting that information, either as a series of HTML pages or in some other format. Note that this request envisions designs that encompass multiple topics - for single topics there is always the "Print" tab.

Ideally the print tab should have the option to print as PDF or HTML or even ODT (OpenOffice, which is also based on Java) or DOC files (Microsoft is still widely used, sadly).

The request below copied from the FAQ page:

It would be nice to allow a PDF export of single pages or group of pages. It should be very helpful to organize pages also into trees. This feature will enable the usage of JAMWiki in order to create manuals or documentation.

Exporting pages or groups of pages would definitely be useful. I'd like to get the parser interfaces somewhat more stable before doing any work on alternative output formats, but once the parser settles down it should be relatively easy to allow output of almost any form. If anyone knows of any particularly simple & free PDF tools that would also be helpful. -- Ryan 26-Oct-2006 02:05 PDT

the german wikipedia clone (written in java) at http://www.wikiweise.de has the discussed PDF export features and claims to open source the wikiweise software in the near future.

I see that wikipresto, the wiki software behind wikiwiese, is already available as OS under the GPL, or you can buy a commercial license from the author. I think this model is fairly incompatible with the LGPL of jamwiki... and it would only harm to look at the PDF implementation of it. I really don't believe the author will change this to a business-friendly license like LGPL, as I also don't really believe the wikiweise site will have any better content than wikipedia in the long run... I had a distinct feeling of "censorship we need" when reading it... and I can't really explain it why, but I feel more censorship will never result in better content, just a differently flawed one. Cheers, Csaba 28-Nov-2006 05:31 PST

I've once tried to create a PDF exporter WikiPDFExporter.java in the Eclipse plugin, but I don't have much background knowledge of PDF and the iText library and so the output doesn't look very beautiful. -- Axel Kramer 28-Nov-2006 08:49 PST

If you (or anyone else) are interested in helping LGPL-ing the pdf creation feature of Wikiweise, drop me a line (mail @ ulrich-fuchs . de). I alone cannot maintain that code as good as I want to, and I think that code has a lot of potential (it's the Tex algorithm implemented in Java with the additional feature of placing images near the text they belong to - as far as I know there is nothing else like this worldwide), but it's in a state where it needs a lot of refactoring. - Uli

A number of projects are using the OpenOffice jar files and binaries to generate PDF files, and even interoperate with OO documents of all kinds, which implies interoperating with MS Office documents as well. Memory suggests that this is a well-documented capability. -- Jack 07-Mar-2007 14:56 PST

The approach described here Generating PDFs for Fun and Profit with Flying Saucer and iText seems to create acceptable PDF files Axel Kramer 14-Jul-2007 07:39 PDT

WYSIWYG Editor

From Evan Prodromou:

I really think that before your syntax gets too complicated, you should take a look at Wikiwyg:

http://www.wikiwyg.net/

It's a fantastic in-browser WYSIWYG editor specifically for wikis. It works by using JavaScript regexes to convert from Wiki markup to HTML and back again, so that users can edit however they want, but the backend only sees Wiki text.

Making it work for MediaWiki right now would be tough, but you're early enough that you can probably make it handle all the syntax your engine does. If you integrate it now, and add new features in a way that keeps it up-to-date, by the time you have full MW syntax parity, you'll have a significantly better product.

Just a suggestion.

A WYSIWYG editor would be a great option for JAMWiki. There is currently some WYSIWYG code that has been commented out from edit.jsp, but it would be nice if it were possible to have a configuration setting allowing an admin (or even a user) to choose a WYSIWYG editor. One consideration is that JAMWiki allows anyone to use a different parser, so it cannot always be assumed that the standard Mediawiki syntax set is being used.

The editor using in Atlassian-Confluence, has more improvement User-Experience i think. Farther more, the edit-cacheing system is very useful.

http://www.atlassian.com/software/confluence/ConfluenceDownloadCenter.jspa

But seems it`s NOT open source. :( -Ray

if someone needs a really neat open source editor, take fckeditor.net. I use it at work in your tomcat apps. performs great!

Testing

"Fuzz Testing"

From NickJ:

Hi Ryan, The Fuzz Tester source code is now on the web. There's also a video that was shown today at the WikiMania Hacking Days about Fuzz Testing MediaWiki if you're really keen - it's 220 Mb, and in XviD format. From your perspective, what you'd want to do would be to update the configuration section (to remove the dependency on MediaWiki's commandline.inc, which is only used for getting the command-line options and for knowing the path to some things which are then used in the configuration section) (or alternatively if you have a MediaWiki install, just drop this into the maintainance directory and use the command-line options to specifiy the URL to your wiki plus which specific tests to run), and then write a test class or classes specific to JAMWiki (you'd probably copy one of the other tests that extend pageTest, such as editPageTest). If you do end up doing such a thing, please send me your changes and the bits that I can include (e.g. any JAMwiki test classes) I will be happy to add to the fuzz tester. -- All the best, NickJ.

Installation

Allow the option for a script-based install

Some users may prefer to install / upgrade JAMWiki using scripts rather than via an automated web interface. It should be reasonably easy to implement this functionality, in which case the install instructions would just be slightly different.

Database owner vs. database user

Provide the capability to specify a "database owner" who can create and modify tables vs. a more standard "database user" who can simply query and update tables.

Multi-server Support

Currently some aspects of JAMWiki may limit installations to a single server - image upload adds a file to a single local filesystem, and file-persistency mode will only support one server. Some of these limitations can be overcome by using NFS mounts or a storage area network, but others should be addressed from the software itself.

technical features

OpenSocial API support

See above under social features.

Mediawiki API Support

Mediawiki is now offering a somewhat standardized API for interacting with bots and scripts - see http://meta.wikimedia.org/wiki/API for details. While it is probably not feasible for JAMWiki to offer compatible support (JAMWiki is not written using PHP), it should be feasible to ensure that JAMWiki offers similar functionality.

I've taken a look into the API's wiki. The std API is no more than a Web Service offering various queries and formats. This can be done here too with Apache Axis 2 in a servlet container. Is there a need for at all? It would take some time to code but if no more than 10 % of the users will use it, it seems to me like a waste of time! --Michael-O

My thinking is that this issue is on the very long-term to-do list. It would be nice to have as a way of offering additional compatibility with Mediawiki, but there are features still missing from JAMWiki that may prevent a full implementation. That said, if someone wants to work on this they are more than welcome to do so, but for those who are just looking for some way to help there are other issues that are probably higher priority. -- Ryan 20-Jul-2007 16:57 PDT

Saying "if no more than 10 % of the users will use it, it seems to me like a waste of time! --Michael-O" is absurd. That ten per cent are by definition the most technically astute and advanced users who are integrating jamwiki into other applications, say on intranets or other products. Those are the most important users of any component or application. They drive everyone else's use and inhabit niches that competing wikis cannot. So there's really nothing more strategic than supporting mashups and so on.

SCRAPI - a contrary position?

Another, contrary, position, is that an API is a bad idea. A SCRAPI (screen-scraping supported as an API) will be used/found anyway by sophisticated users, so why bother "blessing" certain functions with a different API interface? Just make the actual URIs of the pages and functions that are invoked work just as well for mashups and other programs and front ends as they do for users of jamwiki's own web interface. This has several huge advantages:

• there will never be a gap in the functionality, i.e. API doesn't do something the main interface does do, which leads to people screen-scraping it anyway
• it forces strict URI discipline on jamwiki which removes garbage and cruft in URIs and forces them to be mnemonic and human-readable as all good URIs must be - it will also force verbs to be short and hierarchies shallow
• it will encourage other end user Java components to adopt a similar approach and thereby copy the names of verbs ("save", "edit", "print", etc.) and functionality of jamwiki exactly, easing integration with those other programs

JSR-168 Portlet Support

See also Comments:JAMWiki as JSR-168 compliant portlet. Consider adding JSR-168 / JSR-286 capabilities to JAMWiki. More and more standard compliant portal platforms emerge on the commercial or open source market, and most portal projects need a wiki system.

There are more and more portals, true. But JSR-168 is not very easy to implement, I think. And WSRP (webservice portlets) might have a brighter future. Régis Décamps 24-Jul-2007 14:17 PDT

Java content repository

Keep an eye on JSR-170 (Java content repositories) and consider its applicability to Wikis.

I am building a subject map engine (subject maps = topic maps on steroids) using the JCR. It's my present intention to federate JAMWiki with TopicSpaces (will be LGPL when released). A topic map serves as a fully relational index into local and foreign information resources, all indexed against subjects. It strikes me that JAMWiki is an ideal platform for generation of content to be indexed and federated with indexed information resources located elsewhere on the web. For the moment, I don't see a need for JAMWiki to use the JCR, though I won't say it's out of the question. From my perspective, content as found at a wiki is self indexed (full text), but would also be full-text indexed in TopicSpaces such that a query to the subject map will turn up more instances than found locally. As I have mentioned in another post on the WikiReference object, I'm interested in rendering information resources more addressable than simply at the page level. That's because, it seems to me, the comments fields and other content may end up representing discussions that are mappable themselves in the IBIS (Dialog Mapping) format. I want to be able to point to specific instances of pro/con arguments, questions, and responses to questions. All in all, JAMWiki looks to be the platform of choice for federation with TopicSpaces. --Jack 07-Mar-2007 14:49 PST

IMHO it would be nice to have a common JSR-170 based framework for all the Java wikis around in an apache.org based project. See:

• Apache JSP Wiki Proposal discussion
• ApacheSling

-- Axel Kramer 19-Sep-2007 11:30 PDT

Store less text for topics

Currently even the smallest change to a topic will store an entire copy of a topic as a version in the database. For a site such as Wikipedia that would mean huge amounts of data would need to be stored due to the size and number of articles. Storing changes as diffs has its own problems due to the need to apply numerous diffs to view changes between article versions, but there may be an another solution - perhaps a hybrid solution, or some other option.

You could consider implementing a "continuation edit" feature. If a version is changed consecutively by the same user within a specified time period (say 20 minutes), instead of a whole new version, just update the version to reflect the continuation change. That doesn't exactly solve the problem entirely, but it's one step in the right direction. -- scroco 28-Aug-2006 14:40 PDT

That might work, the only problem would be if a user wanted to revert one of his own changes. This issue is probably not going to be addressed for a long while, so hopefully someone will eventually come up with a suggestion that is totally obvious, and really easy to implement. Or at least I can hope for that :) -- Ryan 28-Aug-2006 15:14 PDT

I would like to support this continuation edit, it is a real blessing. For example it is implemented in TWiki with a 60 minute time span. The problem with the user desiring to go back is made transparent you allowing as part of the save option, to save as a "checkpoint". Normal save will work in continuation edit, checkpoint will force a new version. -- I would like to add that the technical level of storage requirements may be even less important than the social one, the ability to compare meaningful versions. Having 4 versions per user within a few minutes makes version comparison a task for experts, not normal users.

I sugguest using reverse diff. We store the latest version in the DB, and diff between each other versions. That way, reading the currect version is very fast. Comparing revisions is slower, but it's not what people ask the most.

That solution could work very nicely. At the moment I don't think there are any fast Java-based diff tools, but given some time that will hopefully change, and this approach would address pretty much any concern about tradeoffs between speed and storage. Thanks! It will definitely be looked into! -- Ryan 13-Oct-2006 16:33 PDT

Zipped topic content discussion moved to Tech:Zipped topic content

And what about a SubversionDataHandler? Actually, that would require to change the API of DataHandlers to split what deals with metada and article content.

Architecture and design

Non-embedded parser

It might be worthwhile to turn the parser into a standalone tool, which would have several advantages:

• It would force the interface to be cleaned up.
• It would allow others to use the parser as an independent tool, likely inviting additional development and spreading the stress of remaining mediawiki format compliant among many other tools that have a need to read/write this de facto standard format

See Tech:Parser isolation

= contrary position - keep mediawiki format absolutely central

A good reason NOT to do this is that the option to swap in another parser that obeys a format other than mediawiki's native format will be very tempting to a lot of users. Supporting such users will distract from the very difficult job of keeping up with mediawiki's native format so there are absolutely no pages written in mediawiki that aren't instantly portable back and forth to jamwiki.

Even the slightest failure in this regard is disastrous, it could cause entire populations using specific languages to stop using jamwiki (imagine if the way some character that occurs only in Hindi is treated differently in jamwiki and it causes a billion people to be unable to import readable Wikipedia pages into jamwiki without errors). Accordingly splitting development effort is unwise.

If people, especially sophisticated developers, begin to think of jamwiki's mediawiki format compliance as "optional" or a "parameter" they can change, the entire project can die dead right there. Or worse, lead to PHP and "real" mediawiki invading Java shops. Which is something we really don't want to see. ;-)

Addon, plugin, extension

It would be a huge design improvement to have the ability to write extension / plugin / addon. However, Java provides good tools for this and it's less reliable to have two ways to do this. If mediawiki extensions can't be supported then probably the Java environment has to be leaned on heavily.

See Tech comments:addon

Wiki Engine

There is a wiki engine called Radeox on http://radeox.org. Someone had a look at it or have experience with it? I'm curious. Mike 12-Jul-2007 13:57 PDT

I had a look on SnipSnap (which is now a dead project) and Radeox was the engine behind it. Radeox seems to be pretty inactive, too. User:Régis Décamps 29-Jul-2007 15:12 PDT

Radeox has been forked be the former lead maintainer. see Forking Radeox Kees.

Hibernate

I personally like the ease of Hibernate to support at least 20 different databases out-of-the-box. Don't mention the avoidance of writting SQL code. I don't mind write SQL scripts, however it annoys me to write and maintain SQL code for more than one database. Why have you chosen to use the current approach? Mike 16-Jul-2007 17:57 PDT

The short answer to why Hibernate isn't being used is that it's not a technology that I'm familiar with, and it wasn't a part of the original Very Quick Wiki code base on which JAMWiki was built. The longer answer is that when I started re-organizing and re-writing the database code I looked at Hibernate, but based on their documentation these were the pros & cons that I saw:

• Database-independent, meaning that once database code is in place to manipulate an object it should work on any supported database.
• Integrated caching, which would simplify any caching architecture used by JAMWiki.
• Connection management, which is always a good thing.

vs.

• Additional learning curve for contributors, myself included. Most web application developers know SQL, but not everyone is familiar with Hibernate.
• The JAMWiki database schema is intentionally quite simple, which means that most SQL code can be written once using ANSI SQL and only translated into a database-specific version for corner cases.
• I'm generally suspicious of abstraction layers - the devil is usually in the details, and I didn't want to commit to Hibernate only to later discover that some minor capabilities that might have been simple with SQL would be complex with Hibernate.
• Although it's grown significantly, I'm generally trying to keep the final JAMWiki WAR file as small as possible, and only include libraries that absolutely need to be there.

So that's the long answer. I'm definitely not opposed to Hibernate, but I don't want to switch without having a list of reasons why doing so is a good idea, and also some reassurance that using Hibernate will simplify the JAMWiki code and we won't still need database-specific hacks to deal with issues such as the fact that HSQL requires its tables to be created with the HSQL-specific "CACHED" parameter. If anyone can make a convincing case as to why Hibernate should be used (and ideally write the code!) then it's definitely something that could be integrated. -- Ryan 16-Jul-2007 21:15 PDT

After the release of 0.6, I would like to write something like a HibernateDataHandler. I will implement it in addition to the existing DataHandlers as AddOn, so it can be tested if it stable, easy to understand and maintainable. I already found the option for the cached tables with HSQL: cfg.setProperty("hibernate.connection.hsqldb.default_table_type","cached");

I'm going to write a draft on Tech:Hibernate Mike 03-Sep-2007 12:45 PDT

Provided it can be done as an option rather than a default it sounds like a great idea. If it proves to be easier to maintain and there aren't any evil corner cases then we could consider getting rid of the legacy code, but that code is fairly well tested at this point so I don't want to toss it overboard yet. Thanks for looking into this! -- Ryan 03-Sep-2007 20:14 PDT

I've just committed a change to fix a DB2 issue that changed the majority of the SQL constraint names - hopefully that doesn't mess up any work you're doing on Hibernate, but if it does and you need help integrating the new SQL let me know and I'd be glad to help make updates to any Hibernate code. -- Ryan 04-Sep-2007 23:24 PDT

Use of Spring Dependecy Injection

I would like to see WikiBase and Utilities as Spring Bean. I want to test my TiddlyWikiParser, but it directly invokes "WikiBase.getDataHandler().writeTopic()". Because WikiBase is a Singleton class I cannot override it in my test case with a mock class to check if this call is invoked correctly. I'm going to check what have to be done for this. Mike 20-Jul-2007 10:51 PDT

Here are my results. There are a lot of singleton classes, which depend on each other. Eg WikiBase depends on Environment, UserHandler, DataHandler, Utilities and SearchEngine. Changing WikiBase to a Spring bean would require to touch almost every class, even all servlet classes, because instead of static methods they become instance methods. However it's currently very hard to write test cases, because these singletons have hardcoded relationships between them. In my opinion it's worthy make them Spring Beans, because JamWiki already uses Spring library and it much easier to write test cases. Mike 20-Jul-2007 12:55 PDT

Is is sufficient to simply make the constructors of these classes public, or do the utility methods need to be non-static? I'd rather avoid having to do:

Environment env = new Environment();
String value = env.getValue("PROPERTY_NAME");

every time a utility method is needed, but if making the constructors public solves the problem then that would be an easy solution. -- Ryan 20-Jul-2007 15:35 PDT

I must commit that it would be really a bloody operation. In fact it rather looks like that:

There would be definitions of beans in WEB-INF/jamwiki-servlet

<bean id="environment" class="org.jamwiki.Environment">
</bean>

<bean id="wikiBase" class="org.jamwiki.WikiBase">
  <property name="environment" ref="environment"/>
<bean>

and instance variables in classes

class WikiBase {
  Environment environment; // + Getter/Setter methods
  otherMethod() {
    environment.getValue(PROPERTY_NAME);
  }
}

It's described in details on http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-dependencies The Spring Framework will create one instance of Environment and fill the environment variable in WikiBase when it is started. It's a nice way of a more loose coupling of classes. However static methods call must be replaced with instance calls in these case. Mike 20-Jul-2007 17:16 PDT

Add ability to parse jsp tags

I would like to see the ability to use jsp tags from within wiki pages. Especially because in our case JAMWiki runs on top of another server, that has its own tags library. If we could use those tags from within wiki pages, it would make the wiki very powerful.

I found a page where a workaround is described that could solve this problem: http://groovy-news.org/e/page/axelclk?entry=how_to_integrate_a_gwt (I didn't try this myself yet)

It would be great to have this as default functionality. Hans 29-8-2007 21:25 CET

"All Templates" Page

It would be a convenient resource if one of the special pages available to users was an "All Templates" page, which (obviously) lists all templates that are in place in a given Wiki. Something like "Special:Templates" would be appropriate.

This feature has been requested previously - my only concern with implementing it is that Mediawiki offers this functionality using their namespace search. Namespace search for JAMWiki probably isn't going to be available for a while, so provided no one would be upset if the AllTemplates page is removed once JAMWiki namespace search comes along then it should be easy to add.

On a side note, the section edit links on this page seem to be messed up. I'll investigate. -- Ryan 04-Dec-2007 08:40 PST

A a follow-up, I decided to try solving the "All Templates" problem by simply putting a [[Category:Template]] tag on all my templates, inside a of a NOINCLUDE tag. However, it seems that the Category parser does not work properly when Categories are listed inside of NOINCLUDE tags. The Category box still gets drawn at the bottom of the template's page, but the Category Listing itself does not contain the template. For example, if I put

<noinclude>[[Category:Template]]</noinclude>

on the Template:MyTemplate page, the Template:MyTemplate page will list that it is part of Category:Template, but the Category:Template page itself will not show Template:MyTemplate on its listing. I hope that was clear.

For now we're probably just going to write our own tool to generate an All Templates page. P.S. The edit link for this section is still broken. --Ean 31-Jan-2008 10:44 PST