Light-weight, fast, simple and powerful!


This page is intended to serve as a “white board” to assemble the requirements and design ideas for the feature talked about in this forum thread.

Please discuss this design here and not in this page.

Use case

We currently see a need to increase user flexibility and simplicity of use by possibly introducing a sort of typed variables.

This would allow us to store a page's content based on page type.

  • By default, there would only be one page type (“basic page”) which equals to the current Page.
  • By default there would be no interface to create new page types except the Plugin API.

This would increase flexibility of the core, keep the default simplicity of the core's interface and would allow developers like “M” to create a “page type management” plugin or a plugin that simply creates page types through the Plugin API.


These requirements were distilled as it were from the forum topic mentioned at the top. These will probably need to be changed/tweaked.

The Wolf CMS core should have “variables” of sorts.

  1. Each variable should be one of a set of basic types:
    1. text,
    2. onoff,
    3. dropdown,
    4. radio
  2. Each variable should have:
    1. an id,
    2. a value specific to its variable type,
    3. field description (used for displaying in a form)

The Wolf CMS core should have “page types” of sorts.

  1. You should be able to combine variables into page types.
  2. You should be able to select a page type from a drop down box which defaults to a “basic page” page type when creating a new page.
  3. There should be only one page type (“basic page”) which equals to the current Page by default.
  4. There should only be a Plugin API interface to create new page types by default.

The Wolf CMS core should allow for a Plugin API to manipulate pages.

  1. There should be a “create page” function.
  2. There should be a “delete page” function.

The Wolf CMS core should be able to generate a form based on the page type associated with the page. This form is in essence nothing more than a grouped set of form-elements which each represent a variable.

Initial technical design/proposal

This is a proposed/possible technical implementation of the above requirements.

The Variables

The variables that are specified in the requirements section could be implemented as subclasses of the (altered/updated) PagePart class, like:

  1. TextPagePart,
  2. BooleanPagePart,
  3. SelectPagePart,

The PagePart class and its subclasses would implement a number of functions that would:

  1. Generate HTML form field code,
  2. Validate values,
  3. Set and get actual values,
  4. Save and retrieve data to/from the DB

For example:

  $myField = new TextPagePart();
  echo $myField->getFormElement();

This can be achieved since in essence there are only about six core DB types:

  • Integer (mediumint and bigint)
  • Float
  • String (say with a max. size of 255 characters)
  • Text (anything bigger than String)
  • DateTime

The page types

The above described PagePart (sub)classes could/should be combined into PageType class instances. Unlike the PagePart class, which already exists but contains very little functionality, the PageType class would be new.

The new PageType class would be little more than a collection of PagePart classes with a field order applied to them somehow.

Creating and then storing a new PageType could be done as such:

  $partone = new PagePart();
  $parttwo = new PagePart();
  $fieldorder = <some description of field order using YAML/XML/Plain text or whatever>;
  $pagetypeOne = new PageType('One', array($partone, $parttwo), $fieldorder);

The field order could be:

  • An array of “tabs” containing
    • An array of “rows” containing
      • An array of fields

Though that is of course a very crude method.

The Page class

Now we let the new PagePart and PageType classes come together in the Page class. The current Page class should be rewritten to be a more generic representation of data. Perhaps it should even have a different name. (FieldType, NodeType and Node perhaps?)

The new Page class would in essence be little more than a representation of various PageParts. By allowing the Page class to be of a certain PageType, we can abstract any “knowledge” the Page class has about the contents it represents into, in the end, PageParts.

Possible Database Implementation

This is a possible implementation of the above in database terms.

UML(ish) representation of idea

I know, this isn't exactly a correct diagram but its good enough. ;-)

Class Diagram

projects/pagetype_requirements.txt · Last modified: 2012-03-14 11:50 (external edit)
Except where otherwise noted, content on this wiki is licensed under the following license:GNU Free Documentation License 1.2
Copyright 2010 / design by yello studio / Wolf CMS Inside