Email support
Can we please get email support a place in the roadmap please? -- Antony Stubbs 25-Jun-2008 19:48 PDT
- Done. Sorry for the delay - I'm on vacation and out of the country until mid-July. -- Ryan 26-Jun-2008 12:52 PDT
Revert to version
Under 0.1.0, the roadmap discusses reverting to prior version from the history tab. Was that feature released with 0.1.0? -- scroco 08-Aug-2006 13:20 PDT
- I'll clarify that on the 0.1.0 description. The functionality is better described on Comments:JAMWiki 0.1.0 and on http://en.wikipedia.org/wiki/Help:Reverting. Basically the functionality that was added was the ability to edit an old version of a page, thus allowing someone to revert a change by clicking on an older version, clicking "edit", and then saving the older version. At present the "rollback" capability that is available to admins using Mediawiki has not yet been implemented. -- Ryan 08-Aug-2006 13:22 PDT
DB transactions
Thought I'd move this discussion to the comments section ...
Since the topic came up, I took a closer look DB persistency, and in PersistencyHandler.writeTopic(...), lies this code (0.3.4 beta6):
if (topic.getTopicId() <= 0) {
addTopic(topic, params);
} else {
updateTopic(topic, params);
}
if (userVisible) {
if (topicVersion.getPreviousTopicVersionId() == null) {
TopicVersion tmp = lookupLastTopicVersion(topic.getVirtualWiki(), topic.getName(), params);
if (tmp != null) topicVersion.setPreviousTopicVersionId(new Integer(tmp.getTopicVersionId()));
}
topicVersion.setTopicId(topic.getTopicId());
if (Environment.getBooleanValue(Environment.PROP_TOPIC_VERSIONING_ON)) {
// write version
addTopicVersion(topic.getVirtualWiki(), topic.getName(), topicVersion, params);
}
String authorName = topicVersion.getAuthorIpAddress();
Integer authorId = topicVersion.getAuthorId();
if (authorId != null) {
WikiUser user = lookupWikiUser(topicVersion.getAuthorId().intValue(), params);
authorName = user.getDisplayName();
}
RecentChange change = new RecentChange(topic, topicVersion, authorName);
addRecentChange(change, params);
}
A successful addition of a new topic would call addTopic(), addTopicVersion(), and addRecentChange(). But those activities are not contained in a single transaction. If addTopic is successful but addTopicVersion fails, the work done in addTopic will not be rolled back. -- scroco 29-Sep-2006 10:26 PDT
- Actually that entire sequence is contained in a single transaction, but the fact that we need to support file persistency makes it a bit hard to follow exactly what's going on. In database persistency mode, initParams() gets a database connection and returns it in an object array; in file persistency mode initParams() does nothing. See DatabaseHandler.initParams() for the database-specific implementation. That database connection is then passed to each method - addTopic(..., params), addTopicVersion(..., params) - and the connection is not committed until releaseParams(params) is called. If any failure occurs then handleErrors(params) is called, which rolls back the transaction.
- The code is a bit obfuscated, but hopefully by dropping the FileHandler class it should be possible to clean things up a bit to be more clear. -- Ryan 29-Sep-2006 10:35 PDT
Right. Now I see it. I missed the fact that writeTopic is overloaded. The writeTopic(...) I was looking at is always called by writeTopic(Topic topic, TopicVersion topicVersion, ParserOutput parserOutput) which handles the transaction properly. Thanks for the clarification. -- scroco 29-Sep-2006 11:09 PDT
Latest setup.jsp from SVN
Instead of getProperty() the method must be renamed to getValue(); otherwise setup.jsp won't compile.
... <option value="<%= DatabaseHandler.DB_TYPE_MSSQL %>"<%= Environment.getValue(Environment.PROP_DB_TYPE). ...
- Thanks, I'll get that fixed shortly. -- Ryan 30-Sep-2006 10:54 PDT
- I didn't realize that this bug was included in JAMWiki 0.3.5. I've released JAMWiki 0.3.6 which fixes the problem. -- Ryan 04-Oct-2006 16:05 PDT
Alternate Setup
Archived from the Feedback page:
Due to my database needs, I want to set up the database and JAMwiki settings by hand, as opposed to running through the automated setup. Can you make the SQL schema available for download? Or even better, make the source available for download other than through subversion (I don't run subversion and have no desire to do so). -- scroco 27-Jul-2006 12:50 PDT
- I've uploaded the JAMWiki 0.1.0 source to http://jamwiki.org/jamwiki-0.1.0-src.zip. Out of curiosity, what is your use case for wanting a script-based setup? If it's something that might have general use then I'd be glad to look at implementing it. I'm not sure exactly how it would work best, but it should be possible to provide a script-based install where JAMWiki could either be automatically installed via a web interface, or else a script could be run to install things and then the web interface install could be bypassed. In any case, if you're willing I'd be interested in hearing what exactly you want to achieve and then see if support could be built into JAMWiki. -- Ryan 27-Jul-2006 13:00 PDT
Thanks for posting the source. My situation involves the way we have set up our database security, we have an admin user that owns tables (e.g. "admin_user"), and various other users which access the tables, each with different access rights. So I don't want to create tables using the same user that will be accessing them. And further, when querying them, I'll be prefacing the table names with the owner name (e.g. admin_user.wiki_table). I'll probably need to modify the source to accomplish that. Do you have any plans to externalize all the SQL into a properties perhaps? Or do you plan to support EJB architectures? -- scroco 27-Jul-2006 14:10 PDT
- It shouldn't be too difficult to move SQL into properties files, although the caveat for anyone who changes those properties is that you would need to update those properties to match your schema after JAMWiki updates. The case for a "database owner" vs. "database user" is a good one, and I'll add that to the Roadmap, including the possibility of a script-based install. As to plans to "support an EJB architecture", I'll admit to not really looking at EJB's in several years - when they first came out my thought was that it was a lot of extra code for not much benefit, but things may have changed. If you have ideas or suggestions regarding EJB usage please share them, and if there are advantages I'd definitely be interested in exploring them. Thanks for the feedback! -- Ryan 27-Jul-2006 14:27 PDT
Cleanup
This page looks much better after the cleanup, and the removal of the Changelog items. Thanks! -- Ryan 25-Jul-2007 21:46 PDT
Keeping an eye on jsr170?
Archived from the Feedback page:
In the road map it is mentioned that you keep an eye on jsr170.
The first time I saw this specification I thought it would be ideal for a wiki. It has import/export, versioning, access control, xpath queries etc... All you need for the data-side of a wiki. Any change of being the first wiki to have this jsr as a base? -- [Kees]
- It would be great if JAMWiki added support for that specification, but at the moment it's fairly far down on my list of priorities - not because it isn't a priority, but because there are so many important things to do. It's always possible that someone else may start working on it, but otherwise I suspect it will be a while before JSR-170 is supported by JAMWiki. -- Ryan 20-Dec-2006 23:50 PST
captcha
Not sure whether this should be in the list for 0.6.x since it wasn't approved, but it seems urgent: captcha needs to be an option in the permissions system since "require captcha to edit" is a permission level
credits
Credits for authoring also need not to be hardwired but instead to be part of BottomArea and easily removable or customizable (more or fewer names, etc.); You don't want silly pseudonyms to have to be displayed, or lots of IP numbers; It's also not correct to call all non-real-names "anonymous" since often someone responsible knows who they are and this might be legally thorny. If one associates all bald IPs with the tag "anonymous", fine, but it is just as important to be able to put another tag on specific ranges or lists of IPs.
Also, block IP and ban user should not be confused. One implication of this is that users should be able to claim specific IP numbers as themselves post-facto, and that a much softer, easy to challenge and undo, way of associating IP numbers with an identity or "user" might be required (though it's probably better to associate them with a faction that might only have one person in it).
many saving errors
For some reason edits to this page are especially likely to result in this error:
"An unknown system error has occurred. The error message is: java.lang.Exception: Failure while executing insert into jam_topic_version ( topic_version_id, topic_id, edit_comment, version_content, wiki_user_id, edit_type, wiki_user_ip_address, edit_date, previous_topic_version_id ) values ( ?, ?, ?, ?, ?, ?, ?, ?, ? )."
It's been seen at least a dozen times on this page alone.
Preferred solution among commercial users?
Not just yet! You write that you want to make jamwiki a preferred solution among commercial users. The most important features to reach this goal are, based on my experience, LDAP-integration, user-rights based on LDAP-groups and a wysiwyg editor. I would like to see theses three points in your roadmap for upcoming releases. I work for a large german car manufacturer and we are searching for a new wiki-solution.
- The major development planned for the 0.7.0 release is an upgrade to the next version of Acegi, which should vastly improve LDAP integration. As to a WYSIWG editor, that's been requested by a number of people, and I suspect that someone will eventually contribute patches to integrate one of the many Javascript editors out there into JAMWiki. The software will continue to improve, so given time it will eventually meet the need of large companies as well as that of small companies and individuals. -- Ryan 08-May-2008 08:07 PDT
- Hi Ryan, thanks for yout answer and for your work on JAMWiki as well! I'm looking forward for the 0.7.0 release to test LDAP integration. The WYSIWYG editor is not my favorite feature, but my boss likes this. The only things i really need is a way for editing tables and integrating images in an article in a more simple way. The wiki syntax for tables and images is the biggest problem for new users. For Mediawiki there is an FCKeditor extension that works for me, and i hope that someone will migrate this to JAMWiki. Is there an extension mechanism in JAMWiki?
- The current release does include basic LDAP support, and there have been success reports, but I don't use LDAP personally so I can't verify how well it works; the new Acegi version should make it more flexible and robust. As to extension mechanisms, that's something that's been implemented slowly, but a full implementation is most definitely in the long-term plans. Since the first release the syntax parser has been a plugin, it's fairly easy to switch out the search engine, etc, but there isn't yet an "official" plugin mechanism. We're getting close, and each release makes it a bit easier, but I'm hesitant to implement anything until either someone comes along with a really good implementation or else the code reaches a point where the best solution is obvious. The problem with plugins is that once you support them you can't change the API, so I'd prefer to move slowly before getting stuck with a sub-par implementation. -- Ryan 13-May-2008 09:15 PDT
- Hi Ryan, thanks for yout answer and for your work on JAMWiki as well! I'm looking forward for the 0.7.0 release to test LDAP integration. The WYSIWYG editor is not my favorite feature, but my boss likes this. The only things i really need is a way for editing tables and integrating images in an article in a more simple way. The wiki syntax for tables and images is the biggest problem for new users. For Mediawiki there is an FCKeditor extension that works for me, and i hope that someone will migrate this to JAMWiki. Is there an extension mechanism in JAMWiki?