Development

 -Basic information
 -Character translation
 -The framework
 -Responses
 -Core classes
 -Debugging and logging
 -The standards applied

---

Basic information

PWP consists of about 190 KB PHP code. This equals round about 5800 lines of code, including comments.

Character translation

The class 'wiki/core/WikiEngine' does the translation, using the Perl style preg_xxx functions. It can be changed easily - have a look! When adding new transformations, consider that the regular expressions are time consuming operations: It will slow down your Wiki.

Why aren't translations done upon 'Save'?

It is not possible to re-convert HTML into Wiki code. Take a tag EM as example: Does it come from '/' or from ''? Or is even plain HTML allowed and the user did type actually '<em>'? You can play this game further: An external link, was it an inline link or have there been square brackets ']' around? What about a user leaving two empty lines between text passages for clarity - PWP will convert this into one paragraph, of course.

All the samples show that a translation upon 'save' would alter the user input. The user will be confonted with diffrent text layout on the next call to 'Edit'. This behaviour is not acceptable. Wiki mark-up must be converted at the moment of the page delivery into HTML. To speed up this process, the cache was implemented.

The framework

PWP is based on a framework - or better: on a part of a framework - which makes a structured development of bigger PHP projects possible. One Request is an incoming POST/GET from the client. This request gets translated into a chain of responses. The main script run.php iterates through all responses, as long as the current response requests an new response (state change). Every response implementation is derived from the base class Response using a template pattern for the methods verify() and service().

verify() has to check all required incoming parameters and sets default values if anybody tampered with the parameters. (Never trust user input.)

service() executes the logic of the response, e.g. creating a new Wiki page.

A chain of responses might look like wiki/CreatePage » wiki/EditPage » out/HTML. The first response creates a new and empty page based upon a parameter supplied by the client. The second response loads a page for editing. The third response prints HTML header and footer.

Such a chain is very flexible: By using wiki/EditPage » out/HTML one would load a page for editing. The same code gets executed as on the creation of a page.

Responses write directly towards STRDOUT (echo). They get the output of former responses passed in a $buffer and may add own output at the beginning of the buffer or after the buffer. An array $args gets passed along the chain of responses.

One or more calls to $gError->add() will interrupt the chain after the currently executed method (either verify() or service()) and redirect to etc/Error.

The framework itself consists of run.php and wiki/core/Response together with two error handling classes.

Responses

All responses are stored under wiki/resp/{subdir}. 'out/HTML' is usually the last response in a chain. It contains the menu and the HTML header and footer. This response will also be applied upon the delivery of a cached page. This way you can add dynamic content in header and footer in any situation.

Core classes

The classes Trash, Data, History, Upload and Statics (in wiki/core) are rather a repository for functional written methods. They are to be accessed using static calls (::). Their implementation could be more object oriented with inheritance, but it would require to rewrite a big part of the code without gaining speed. All the equal looking tasks like ::clearAll() differ slightly an would need to become parameterised.

Debugging and logging

Debugging requires a call to run.debug.php which is shipped with the Wiki distribution. A log and a list of introspections (see below) will be appended to every HTML page. There are two functions available in the global scope:

• introspect( mixed var {, string message} ) which will print a readable state of the passed variable. All introspections are printed into a table at the end of the page.
• logMsg( string message {, string file name {, int line }} ) will print a logging message at the end of the page.

The standards applied

• register_globals=off must be supported, use $_REQUEST, etc.
• Avoid any warnings. All variables have to be initialized.
• Comment all methods and classes, prefer Java style.
• The script should execute on a local installation on average under 100ms per request.On average, do not load or include more than 10 files.
• Class names are MixedCase words, starting with an uppercase letter.
• Method names are mixedCase words, starting with an lowercase letter.
• Private variable and function names are preceeded by an underscore '_'. They are only to be accessed inside a class / file.
• Class members are identified by a '$m'; '$_m' would be a private class member.
• Global variable names start with a '$g'; '$_g' would be a variable to be used only in global scope.
• Parameter names submitted by the web browser begin with an 'i' like
  $_REQUEST[ 'iWebParam' ].
• One class resides in one file with similar name.