Janne Jalkanen wrote:
Yes, plugins can be changed (everything is broken anyway) but nobody has been interested in providing any comments or design so far. If you want to lead the discussion, go ahead!
Janne, It's not necessarily from a lack of interest, it's that this is as you know a volunteer team, and those of us whose participation is based on time available and external schedules don't necessarily have a schedule that syncs up with the development cycle of JSPWiki. I for example have been largely unavailable for the past few months, and am just now going into another period where most of my time will be devoted to a few other things, some related to JSPWiki (e.g., two papers due prior to Christmas and three new projects coming into the new year). I would prefer to have more control over my time allocation but I do have to eat.
(My hope is though that we can survive with rather a minimal set of changes as to encourage people to port their plugins to 3.0. Our plugin system is fairly stable and easy to understand - if there was anything I would change it would be that I would change the way parameters are transmitted. A Map prevents for example multiple parameters of the same name, which is a bit painful. But you guys do plugins more, so please start the discussion!)
I don't have any problem with the parameter handling myself. Most of my issues have to do with plugin paths and deployment. There needs to be some way of specifying compatibility and dependency, and to do so within the code of the plugin rather than some external file. I'm keen to hear more of what John has to say in this regard, and I haven't had a chance to look at the new API you've done (indeed, I didn't notice it in the code as I've been deploying a few wikis which has kept me busy).
Mediawiki (which is about 90% of the world's wiki installations) does not give a list of backlinks when clicking on the title. Neither does TWiki, which probably accounts for a majority of the rest. Therefore the assertion about every other wiki engine is flat out wrong, and just shows that there is a bias towards a particular selection from the beginning. (In fact, I think it is a clunky idea at best. Our ReferringPagesPlugin is superior, since it can be embedded in the LeftMenu.)
I largely agree with this. MediaWiki has the benefit of massive popularity based on exposure due to Wikipedia and a popular development platform, not to say that JSPs are unpopular but they're appealing to a different coding personality.
Our default template could look better, I agree (and I am not too hot on the other skins on it either). Unfortunately, we don't have any graphic designers in the team... If a company out there would like to help JSPWiki, getting someone with a very good eye for loan for a while might be very nice... ;-)
I've got three or four templates *I* think look more attractive than the default, though they were designed for specific branding and would require some reworking. I'd be willing to submit one of them if Dirk or someone wanted to fix up the JavaScript issues that might arise. I do have a graphic design background (though I'm loath to admit it at times). I could post some screenshots if you were interested. A more graphically appealing design would lend a lot more interest to the project. Sadly, people tend to judge things on appearance rather than functionality and the jspwiki.org site is on the barren side. We have some nice new JavaScript functionality which is mostly invisible to the naked eye, so it's a bit of a shame. We look clean but naked. [In some circles that's a Good Thing.] Murray ........................................................................... Murray Altheim <murray07 at altheim.com> === = = http://www.altheim.com/murray/ = = === SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = = Boundless wind and moon - the eye within eyes, Inexhaustible heaven and earth - the light beyond light, The willow dark, the flower bright - ten thousand houses, Knock at any door - there's one who will respond. -- The Blue Cliff Record
