This page is intended to layout how a developer can contribute to dokuwiki.

• Prerequisites
• It outlines the dokuwiki general structure
• Model View Controller
• The directory tree created through darcs pull from the repository.

What's needed to participate

1. A working darcs version
2. A working mail infra … for darcs send to function.
3. 

A wiki topic consist of the plain text, some media files …

When a topic is changed one of the following scenarios holds true ()

1. scenario 1: the latest version is saved as UTF-8 encoded text file, cached and also saved into the attic directory in a gz compressed format.
2. scenario 2: the old version is saved into the attic directory in a gz compressed format. And the latest as UTF-8 *.txt file

The plain text files are stored in UTF-8 encoded format. This is a format most browser support (Is this true? )

I believe plain text (ascii codes 0-127) fits into the encoding scheme. So machine generated files are valid wiki topics. There are some discussions about system generated topics which is nice if properly authorized.

If scenario 1 holds then one have to compare two different gz files. If scenario 2 holds then one have to uncompress and compare with the latest text version.

caching mechanism

topics

media

The MVC Design Pattern is in my opinion a nice pattern to explain the structure of dokuwiki.

• A View is what is rendered into the browser. But how can a view be rendered without some data. This is where the Model comes into the picture.
• A Model is what is stored as a topic on the web-server. But the model is also the topic one can edit with dokuwiki. But for more complex models ie a diff page there needs to be some processing and control. This is where the Controller comes into place.
• A Controller gets a request: ie process a HTTP POST and decides what to do with the request: Save, Cache, … Next it decides which View is responsible for the Response. In dokuwiki there is one Controller doku.php.

doku.php is the controller.

The model consist of a few aspects

• user membership
• ACL
• namespace(s)
• topic(s) (: Is a topic the full path /wiki/development/guide of just guide?)
• media file(s)

The view is what is rendered and how into the browser.

• Topic content
• CSS
• Code highlite
• templates
• Header, Footer etc

: Is this the right place. This shouldn't be a darcs crash course

By pulling now and then one gets new updates from the repo. Darcs will tell you how many patches there are and you can choose which ones you want to pull.

darcs pull

It is wise to change one issue, feature at a time. This is because every darcs patch needs a, hopefully useful, name.

Use your favorite editor. : The editor needs to be UTF-8 compliant.

Check whether your changes were coherent.

darcs whatsnew

Only related changes should be bundled into a patch. Then record your changes and give a good name for the patch.

darcs record

When you want to deliver a patch you can send your patch to Andreas. For this you need a good mail infra.

darcs send

Or when your mail infra is not working or you just want to send your patch by email you can save the patch to a file with

darcs send -o mypatch.patch

and send it as an attachment from anywhere (eg: webmail).