| At line 1 added 2 lines |
| [{TableOfContents }] |
|
| At line 38 added 3 lines |
| !! Complete application |
| ! Catalog app |
| Many applications are just specialized catalog apps. The common example is a CD,DVD, book catalog. But a bug database, a collection of crash stacks (http://www.kerneloops.org) are really essentially the same thing. |
| At line 42 added 4 lines |
| A wiki is a natural fit for catalogs and can mostly be used for that without any additional development of plugins: |
| * use templates to assist with data input |
| * use regular search to find elements in catalog |
| * use tagging if available to get more restricted searches (ex: issues tagged as open) |
| At line 47 added 6 lines |
| A more full featured and custom developed catalog app would often feature: |
| * data validation |
| * forms instead of simple |
| * automatic completion to help with data input |
| * advanced search matching specific data fields |
| * reports, graphs and charts regarding the data |
| At line 54 added one line |
| ! Requirement tracking |
| At line 56 added one line |
| Requirement tracking can be reduced to tagging software or system documentation and producing reports from those tags to check that the requirements are taken into account in the design, the code and tested. This is typically a document-centric activity and many systems are actually based on Microsoft Word or have to interface with it. |
| At line 58 added 5 lines |
| This is therefore a natural fit for a wiki: |
| * documentation can be done inside wiki pages |
| * requirement marking (definitions, references) can be done with simple text markup |
| * search mechanisms in a wiki can locate the text markup of requirements |
| * multiple pages can be merged into one and each requirement, test or other tracked item could thus have its own page to be easily referenced. |
| At line 64 added 3 lines |
| Additional features could include: |
| * cross referencing of requirements and other tracked items |
| * more freedom in the way the documents can be organized and edited |
| At line 68 added 57 lines |
| ! Language learning app |
|
| [Language learning app] |
|
| !!! Implementation ideas |
|
| !! Template plugin |
|
| Scott is into [Velocity templates|wiki Tools] these days and plugins for JSPWiki tend to print a lot of text with some variable parts, so this looks like a good way to design plugins. If most of the interesting parts of a plugin end up in a template, this brings the question of allowing a more generic plugin that takes the template from a wiki page and builds a velocity context to run it. |
|
| A velocity context can provide: |
| * formatted data an objects (e.g. key/value pairs defined in a plugin invocation or in a document referenced by the invocation (raw page, rendered page, attachment) |
| * access to methods and objects |
|
| The wiki could expose methods for: |
| * search in the wiki |
| * information about the user if logged in (actually risky: one user could spy on users accessing a page of his). |
| * access to the rendering engine |
|
| The output could be: |
| * wiki text that is then run through the wiki's rendering engine. |
| * html code |
| * SVG or other in a page that has an appropriate mime type |
| * Javascript code |
|
| !! Wiki services |
|
| To make it easier to develop pages with more behavior (AJAX style), we need the wiki to automatically provide services based on the pages: |
| * a template plugin and a mechanism to get a rendered page without the skin should provide read services easily. |
| * a service to create a page and fill it with data would be useful although it might be relatively easy to emulate that by POSTing to /Edit.jsp?page=<page> |
| * a service to attach a file containing data |
| * renaming and deleting pages |
| * the search feature of the wiki exposed as a service |
| * a service to accept POST of forms and perform some generic action automatically (take keys/values and put them into a wiki page or append them to one. Applying a velocity template is an option here) |
|
| The ability to run code on the wiki side based on parameters received in the request and then compute changes to be made to the wiki (e.g. update multiple pages) might be useful but really seems less natural. |
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|