This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

A JSPWiki plugin is a tool that can automate actions on wiki pages. The well known PageIndex or RecentChanges pages contain little more than a plugin!

The long formal form to insert a plugin in a wiki page is:

[{INSERT <plugin class> WHERE <param1=value1>,<param2=value2>,...}]

If a parameter contains spaces, you can use single quotes (') around the parameter. INSERT and WHERE are optional and can be omitted.

JSPWiki lets you create your own plugins. These are just simply Java classes that implement the com.ecyrd.jspwiki.plugin.WikiPlugin interface and can be found from somewhere in your class path. The plugins work so that when you reference a plugin on a wiki page, the plugin is invoked and its output is inserted verbatim into the page.

• Installing a plugin

---

JSPWiki Core Plugins#

Some of JSPWiki's features are implemented as plugins. These JSPWiki Core Plugins are available in all out-of-the-box installations.

Contributed Plugins#

Anyone can develop a test plugin, and some folks have been kind enough to list them here and provide either source-code or ready to use .class or .jar's. These Contributed Plugins require that you install them on your own wiki yourself.

Concept Plugins#

Some ideas for plugins that could be developed. If one catches your attention take ownership of it and develop it into something that can be contributed. Or if you have an idea for a plugin that you'd like to see get developed document it here and maybe some kind soul will develop it for you.

Contributed Form Handlers#

WikiForm handlers are in fact plugins, but are intended to work closely with the WikiForms feature of JSPWiki.

Category Documentation

See also WikiVariables

---

Hi,

Dunno if i add my comment at the right place, i hope i do. I'm working for a company which would like to implement its documentation management in a wiki. I'm interested in using your wiki for this platform but i have some issues about some features i need : -Do you have anything to manage the workflow of the documents ? My company wants to implement the ISO 9001 aspects in its documentation.

-Less important but i'd like to implement some forms management in the wiki, like some features of excel... is there anything available for your wiki (plugin...) about that ?

-Are there any issues or limitations about the number of users connected, number of pages... ?

Thanks in advance

Best regards

--AnonymousCoward, 23-May-2007

---

I personally think that ISO 9001 workflow additions are contrary to the goals of wiki. Wiki is fast. Wiki is flexible. Wiki is collaborative. ISO 9001 workflow is step-by-step with checkpoints. It is a means to set up road blocks to make sure everything is done up to standards. You should be looking at something other than a wiki if you need to validate everything at every point of a process.

my 2c

--AnonymousCoward, 08-Jun-2007

---

Workflow is required for document control, checking/approving attachments, and filling and approving forms. Although strictly not a standard wiki function it is required in any project or enterprise CMS, and I don't agree that it shouldn't be integrated into JSPWiki. Wiki does full document and version control of unstructured and generally unrestricted editing of content for the purpose of collaboration and in this context it is useful in an enterprise context. Wiki has the ability to restrict access. Workflow is just an additional sequential restriction on access to wiki collaboration. Integrating workflow into JSPWiki will be a huge benefit to JSPWiki users because it will fill in the small missing piece of functionality in enterprise application of JSPWiki.

An object subject to workflow is basically a template object which has several states each of which can have different access restrictions and which different users/groups can move to the next state (or possibly back to a previous state). Hence it isn't very different from standard wiki functions - it is just a different form of access control. Workflow objects should also be capable of setting different overall access restrictions depending on where it is viewed - for example you would want the lines in a drawing approval table to allow certain fields in each line to be updated in a "drawing entry" wiki, but you may want to view the table as read only when referred to in a "current drawings" wiki or list only approved drawings in the "approved drawings" wiki.

Although you could include workflow in JSPWiki by including a URL pointing to another application like Alfresco for example, the problem with this is that it leads to duplication of a lot of functionality, plus the need to log in twice, which is not really what people want. It is far better to include some basic workflow features in JSPWiki itself.

TWiki implements a workflow implementation which may be worth a look at. http://twiki.org/cgi-bin/view/Plugins/WorkflowPlugin

--AnonymousCoward, 16-Sep-2007

---

JSPWiki 2.5.x actually includes workflow functionality. It's not as easy to use as we would like it to be (there is no real UI, and some coding is involved), but it could be extended to be a pretty powerful system.

--JanneJalkanen, 16-Sep-2007

---

so having this thread of comments on this page is probably a bad idea and, unfortunately, I'm just adding to it... hmmmm.

I see the conflict between the core wiki premise and having CCM (pick any two: configuration, change, and control management, among other meanings) documents. The problem, and I've seen this in several cubicle collectives, is that, currently, no good solution to both sharing knowledge and having the version control / review procedures / authorization protocols required in cubicleland exist. The result is that knowledge is stored in documents that no one knows about, so huge amounts of time get spent re-inventing the wheel.

Simply implementing a wiki in a workgroup's space eliminates a significant amount of redundancy and lost time in trying to find information. However, as mentioned above, in typical size workgroups (50 to 500) adhering to often Draconian and inefficient procedures for publishing any kind of documentation is an absolute requirement. A simple page of acronym listings will have a review process for updates! Without CCM capabilities a wiki will not be allowed into a production environment (at least not in the business I'm in).

So the goals are somewhat conflicting. We need an ISO-9001 compliant wiki! (joke)

Seriously, the inefficiencies and lack of organization largely due to the absence of a means for sharing information that must undergo a psuedo-rigorous approval process are significant. Any method for reducing the amount of banging-your-head-against-the-wall would be drooled over, even if it isn't quite in-line with the original intention. Almost daily I find myself trying to locate documentation on a specific tool or system. Currently this means asking the person next to me if they know anything about it, then the person next to them, then spamming email, etc, etc, etc. Eventually I'll find the documentation. Usually a well-prepared, reviewed and approved, PDF buried in some obscure library on some random network. And I'm one among 200. Imagine not just the 'lost time' but more importantly, the frustration generated by this madness... throughout this workgroup, throughout our company, throughout virtually all companies.

(now's about the time when someone says 'maybe you should cut back on the coffee a bit', so I'll stop.)

--DavidMc, 08-Nov-2007

---

And now I am adding to it too. Is there any way to invoke a plugin from a link? Additionally, can you pass in variables to the plugin from a link?

--LouMasters, 06-Jun-2008

Here's the answer to me own question: Yes, you can call a plugin from a link (and you can even pass it parms if the plugin is coded to handle them). The simplest way to do it is:

1. Create a "wrapper" page that only contains your plugin invocation.

[{'YourPlugin'}]

1. Create your link to this page like so:

[http:WIDRequestDetailsHeadLess]

Additionally, if the plugin is coded to look for http parms, you can add parms to your link like so:

[http:WIDRequestDetailsHeadLess?wid=1234]

--LouMasters, 26-Sep-2008

---

---