The WikiWorkbench standardizes writing, deploying and using wiki applications on Foswiki. It builds on the core concepts of standard Foswiki and establishes a unified terminology to leverage concepts and key benefits known from conventional programming towards wiki applications. These are:
While these concepts are nothing new for a normal programmer, they do have a clear equivalent using Foswiki as an application framework. Wiki applications still are written in TML using your browser on your Foswiki site. However, all bits are managed in a clean way to guarantee that you will still find them years later. People trained to write wiki applications the WikiWorkbench way will immediately know where to look and fix applications written by others, as they all share the same concepts. So by establishing a clear teminology and best practice, you will be able to maintain even large wiki apps consisting of hundrets of different components working together long term.
WikiWorkbench has been developed over the last 5 years working together with a series of companies in need of large scale wiki applications, custom tailored to their business needs, covering fields like
Wiki applications can then be packaged and reused on different deployments like ordinary Foswiki plugins that extend your site. The main difference is that wiki applications are fully developed, documented and maintained using the browser. All parts of an application are a wiki page, so working on an application is done by interacting with the wiki directly.
This chapter gives you a quick overview on how to start a new wiki application. We will create a first custom TopicType and deploy it into a user web. Finally we will create a new topic of that type by using the standard topic factory.
The new wiki application is a web that serves as the container and library for things that you are planning to build and which belong together as one. You might either consider creating one singular wiki application located in one subweb of its own, or separate it into several wiki applications that can be used individually without one another, or which other wiki applications build on top.
When installing the WikiWorkbenchContrib, you will get two new webs:
You won't need to change these as they make up the infrastructure. Take care not to mix up your own stuff with wiki applications coming from third parties. Instead, build up a separate wiki application that won't be harmed when you have to upgrade third party applications later.
This will create a new subweb under the Applications web, that is Applications.MyCompanyApp in our example. This newly created web is the container for all components part of this application. No part of the application is located outside of this web.
In this sense a "wiki application" is the sum of all components stored in the Applications subweb (Applications.MyCompanyApp). You will be able to write and maintain the wiki application by going to this web now.
When finishing or installing a wiki application, the additional features are made available in other areas of your wiki site by a dedicated deployment step. The WikiWorkbench infrastructure helps you in doing so. For example, each TopicType that you will create will have an Install button that lets you establish a link between the area where you'd like to deploy the feature back to the application itself.
TopicTypes make up a hierarchy with a kind of "IS A" relation between parent and child types. So any child type inherits all structural properties of its parents. Parent topics can either be abstract only to let your write wiki applications for sub types not yet in existence but will inherit from this abstract parent topic some time later.
For example: given there's a ContactsApp to model contact data for persons and organizations. There are TopicTypes "PersonTopic" and "OrganizationTopic". Both inherit from a "PartyTopic" as a common root in your application. So both - persons and organizations - are a "party" with regards to the rest of the wiki application.Furthermore, all PartyTopics should be tagged and categorized, a feature being implemented in a separate wiki application that comes with a ClassifiedTopic type. The ClassifiedTopic type itself is implementing two features: that of TaggedTopics and CategorizedTopics. (footnote: these TopicTypes are part of the ClassificationPlugin)
All topic types finally are some kind of a WikiTopic, which finally is the root of all content types as definied in the WikiWorkbench.
In Foswiki a TopicType establishes a label for a specific kind of DataForm to be used by one or more wiki applications.
A wiki application is made up of different components that are used when deploying it to one or more target webs...
You do not need to install anything in the browser to use this extension. The following instructions are for the administrator who installs the extension on the server.
Open configure, and open the "Extensions" section. Use "Find More Extensions" to get a list of available extensions. Select "Install".If you have any problems, or if the extension isn't available in
configure, then you can still install manually from the command-line. See http://foswiki.org/Support/ManuallyInstallingExtensions for more help.
|21 Sep 2015||using Foswiki:Extensions/GraphvizPlugin now instead of DirectedGraphPlugin; support for Foswiki:Extensions/LikePlugin; RSS view tempalte now uses OO-calling semantics to allow TopicTypes to override the defaul format of an entry in a feed; added support for AUTOINC in TopicType factory|
|17 Jul 2015||added support for multi-lingual wiki apps; display TopicType inheritance tree using Foswiki:Extensions/DirectedGraphPlugin; added editors and TopicTypes for all wiki app components|
|16 Dec 2014||added "Default" column to form definitions|
|29 Aug 2014||using new RENDERFORMDEF in FlexFormPlugin for DataForm definition insights|
|22 Apr 2014||improved rendering of revision info in WikiTopics; remove traces of NatSkin css classes|
|04 Apr 2014||fix wikiapp formfield to work on foswiki >= 1.2.0|
|18 Mar 2014||improved thumbnailing for topics; support jquery.validate in topic creator; added dependency on NatEditPlugin|
|01 Nov 2013||simplified application template; hide H1 button when editing a WikiTopic as a H1 is generated by the view template already; better support for NOAUTOLINK; display quality warnings on the view, not in the editor; add support for explicit thumbnail image attachments (those that have a "t" attribute);|
|05 May 2013||implemented full-text rss and atom renderer|
|18 Feb 2013|| fixed topicinfo; removed legacy twb.js file breaking
|07 Jan 2013||first public release|
|30 Oct 2007||first version in svn|
|30 Apr 2007||initial version|
|Release||21 Sep 2015|
|Copyright||2007-2015 Michael Daum http://michaeldaumconsulting.com|
|License||GPL (GNU General Public License)|
|EXT||Makefile||manage||151 bytes||02 May 2019 - 09:27||IvicaPetrinic|
|png||book.png||manage||11 K||02 May 2019 - 09:27||IvicaPetrinic|
|png||exec.png||manage||24 K||02 May 2019 - 09:27||IvicaPetrinic|
|js||jquery.topictitle.js||manage||392 bytes||02 May 2019 - 09:27||IvicaPetrinic|
|gz||jquery.topictitle.js.gz||manage||256 bytes||02 May 2019 - 09:27||IvicaPetrinic|
|js||jquery.topictitle.uncompressed.js||manage||720 bytes||02 May 2019 - 09:27||IvicaPetrinic|
|png||model.png||manage||24 K||02 May 2019 - 09:27||IvicaPetrinic|