nnsoft - PHP

CMS using WACT

nospam@example.com (chnghia) — Thu, 12 Jan 2006 15:23:28 +0100

by Harry Fuecks

Pavel Chtchevaev recently dropped a message into Sitepoint's Advanced PHP forum, annoucing LIMB, a PHP CMS that uses WACT's template engine.

WACT is still in evolutionary stage so significant customization was required by LIMBs developers but it's great to see someone taking advantage of WACT already and turning the results into Open Source. That it's possible to use some of WACT while ignoring the rest is part of WACT's design "philosophy", as collection of components as opposed to a rigid framework.

It's also interesting to look at some of the template source in LIMBs demo (you need to download the source from SF right now if you want to examine the templates although they were available online until today).

(sitepoint.com)

LIMB: File path resolving

nospam@example.com (chnghia) — Thu, 12 Jan 2006 15:10:51 +0100

From the very beginning Limb has been developed in mind to manage several projects being a shared instance. Sometimes projects require a bit different behavior the default one. That's why Limb uses special file path resolving technique.

(limb-project.com)

LIMB - The basic LIMB principles

nospam@example.com (chnghia) — Fri, 23 Dec 2005 10:55:27 +0100

What is site objects?

The central architectural unit of Limb is a site object. Every single piece of Limb CMS data is a site object, be it a workflow document or just a guest book reply.

All site objects are hierarchicaly organized in the objects tree. You can find it at /root/admin/site_structure page.

The site object is defined with set of different attributes. The most important are:

* node_id: integer, specifies the note in the object tree to which the site object is attached

* id: integer, specifies unique id of the site object

* identifier: string, allow to build a human-readable path to the object in the object tree

* title: string, allow the name every object

Why having 'node_id' and 'id'? In future this feature will help aliasing site objects. Currently it's not implemented though and 'node_id' is mostly used.

Actually there're 2 ways of fetching the specific the site object:

* by the full tree path which comprises site objects indentifiers delimetered with /, e.g. /root/catalog/TDD/refactoring

* by the node id, e.g. /root?node_id=92

What is content objects?

There're two types of site objects:

* simple site object.

* content object.

The main difference of the later is its being under very simple Limb version control, every modification results in a new version. This way we resolve concurrent editing. The basic implementation of the content object ties it with a database record. Most of the content object never require any complex O-R mapping and if any the developer is required to resolve mapping manually.

Here goes the example of the content object:

<?php
require_once(LIMB_DIR . 'core/model/site_objects/content_object.class.php');
class article extends content_object
{
 function _define_attributes_definition()
 {
  return complex_array :: array_merge(
    parent :: _define_attributes_definition(),
    array(
     'content' => array('search' => true, 'search_weight' => 1),
     'annotation' => array('search' => true, 'search_weight' => 5),
     'author' => array('search' => true, 'search_weight' => 10),
     'source' => array('search' => true, 'search_weight' => 10),
    )
  );
 }
 
 function _define_class_properties()
 {
  return array(
   'class_ordr' => 1,
   'can_be_parent' => 0,
   'icon' => '/shared/generic.gif',
  );
 }
}
?>

What is site object controller?

Every site object linked with some controller, it defines what kind of actions the site object has. Since Limb 2.3+ it's possible to assign different controllers to site objects of some class.

Here is the example of site object controller:

<?php
require_once(LIMB_DIR . 'core/controllers/site_object_controller.class.php');
require_once(LIMB_DIR . 'core/lib/locale/strings.class.php');
 
class article_controller extends site_object_controller
{
 function _define_actions()
 {
   return array(
    'display' => array(
      'template_path' => '/article/display.html',
    ),
    'admin_detail' => array(
      'template_path' => '/admin/object_detail_info.html',
      'popup' => true,
      'JIP' => true,
      'img_src' => '/shared/images/admin_detail.gif',
      'action_name' => strings :: get('detail_info'),
    ),
    'print_version' => array(
      'template_path' => '/article/print_version.html',
      'action_name' => strings :: get('print_version_action', 'document'),
      'display_in_breadcrumbs' => false,
    ),
    'edit' => array(
      'popup' => true,
      'JIP' => true,
      'action_name' => strings :: get('edit_article', 'article'),
      'action_path' => '/article/edit_article_action',
      'template_path' => '/article/edit.html',
      'img_src' => '/shared/images/edit.gif'
    ),
    'publish' => array(
      'popup' => true,
      'JIP' => true,
      'action_name' => strings :: get('publish'),
      'action_path' => '/doc_flow_object/set_publish_status_action',
      'img_src' => '/shared/images/publish.gif',
      'can_have_access_template' => true,
    ),
    'unpublish' => array(
      'popup' => true,
      'JIP' => true,
      'action_name' => strings :: get('unpublish'),
      'action_path' => '/doc_flow_object/set_publish_status_action',
      'img_src' => '/shared/images/unpublish.gif',
      'can_have_access_template' => true,
    ),
    'delete' => array(
      'JIP' => true,
      'popup' => true,
      'action_name' => strings :: get('delete_article', 'article'),
      'action_path' => '/article/delete_article_action',
      'template_path' => '/site_object/delete.html',
      'img_src' => '/shared/images/rem.gif'
    ),
  );
 }
}
?>

What is action?

The action is ... action can be whatever you want! There're few base actions that ease the developers life though.

The action is transferred via 'action' attribute of the $_REQUEST, so

http://somedomain.com/root?&action=edit&node_id=83

will require the site object with node id 83 to perform 'edit' action

If we had the object with node id 83 placed in /root/documents and it had 'article1' identifier, the request below would mean the same:

http://somedomain.com/root/documents/article1?action=edit

Let's examine the 'edit' section of the article controller. Well first of all we have 'action_path' set to /article/edit_article_action', the controller is going to fire 'edit_article_action' (the path to the class is found with file path resolving technique)

<?php
require_once(LIMB_DIR . 'core/actions/form_edit_site_object_action.class.php');
class edit_article_action extends form_edit_site_object_action
{
 function _define_site_object_class_name()
 {
   return 'article';
 }
 
 function _define_dataspace_name()
 {
   return 'article_form';
 }
 
 function _define_datamap()
 {
   return complex_array :: array_merge(
    parent :: _define_datamap(),
     array(
      'article_content' => 'content',
      'annotation' => 'annotation',
      'author' => 'author',
      'source' => 'source',
      'uri' => 'uri',
     )
   );
 }
 
 function _init_validator()
 {
  parent :: _init_validator();
 
  $this->validator->add_rule(new required_rule('title'));
  $this->validator->add_rule(new required_rule('author'));
  $this->validator->add_rule(new required_rule('article_content'));
 }
}
?>

Simple, isn't it?

What about action template?

Also in the 'edit' action of the article controller we have optional attribute 'template_path' set to '/article/edit.html', the controller is going to initialize WACT template and pass it to action. This template might look as follows:

<core:WRAP file="popup.html" placeholder="content">
 
<form method="post" name="article_form" id="article_form">
  <table width=100% border=0 cellspacing=0 cellpadding=0 height=100%>
  <tr>
    <td colspan=2 class=table-title><locale:STRING name='article_edition' file='article'> 
  <h3> "<fetch:MAPPED>{$title}</fetch:MAPPED>" </h3></td>
 
  </tr>
  <tr>
    <td colspan=2 height=100% valign=top class=com4>
        <table width="100%" border="0" cellspacing="0" cellpadding="0"
        style='padding:5px 10px 1px 5px;' id=param_req_content>
        <col align=right width=200 class=labels>
        <tr>
 
          <td><label for="identifier"><span class='req'>*</span>
          <locale:STRING name='identifier' ></label></td>
          <td><input type="text" name="identifier" id="identifier"
          label="Identifier" class='input'></td>
        </tr>
 
        <tr>
          <td><label for="title"><span class='req'>*</span>
          <locale:STRING name='title' ></label></td>
          <td><input type="text" name="title" id="title" 
          label="Title" class='input' size='40'></td>
 
        </tr>
        <tr>
          <td><label for="annotation"><locale:STRING name='annotation'></label></td>
          <td><textarea class='textarea' name="annotation" id="annotation" 
               label="Annotation" cols='40' rows='5'></textarea></td>
 
        </tr>
        <tr>
          <td><label for="author"><span class=req>*</span>
          <locale:STRING name='author' file='article'></label></td>
          <td><input type="text" name="author" id="author"
          label="Author" size="60" class='input'></td>
 
        </tr>
        <tr>
          <td><label for="source"><locale:STRING
          name='source' file='article'></label></td>
          <td><input type="text" name="source" id="source"
          label="Source" size="60" class='input'></td>
 
        </tr>
        <tr>
          <td><label for="uri"><locale:STRING name='uri' 
          file='article'></label></td>
          <td><input type="text" name="uri" id="uri" label="URL" 
          size="60" class='input'></td>
        </tr>
      </table>
    </td>
  </tr>
  <tr>
    <td colspan=2 align=center height=30>
     <action_button action="edit" name="update" type="submit"
     id="update" value="update" reload_parent="true" class="button">
    &nbsp;
    <input name="cancel" type="button" id="cancel" value="close"
    onclick='window.close();' class="button">
    </td>
  </tr>
  </table>
</form>

Every action has its View in the $_view attribute (rarely used though, our templates have active behaviour).

Extra stuff

Site objects passed around as arrays in the Limb, turning into objects only when it's needed. This allows to decrease unnecessary overhead greatly. Furthermore, they've transfered to WACT templates as array datasets which allows to use all the nice features of WACT.

(limb-project.com)

Design Patterns in PHP - Factory Method and Abstract Factory

nospam@example.com (chnghia) — Thu, 22 Dec 2005 10:22:51 +0100

by David Fells

Normally, in object oriented programming, object creation is not difficult. But what if your object needs to be created based on different conditions or other matters of context? Then you will spend hours in debugging and updating --unless you know about design patterns. David Fells explains how they work, and uses the creation of a maze to illustrate his points.

Overview

In object oriented programming, object creation - also known as instantiation - is an implied requirement. Object must at some point be created for use. Obviously, creating objects is not difficult task and most languages, PHP included, have simple and intuitive syntax for doing so.

When developing larger, more complex systems though, object creation can become difficult. There are situations where different objects may need to be created based on different conditions or based on the context of the object creating it. Creating objects of concrete type explicitly in code can make these situations a nightmare when it comes time to make revisions and additions. When a new class is introduced, you get to follow a trail of code and commence the hours of debugging that will inevitably follow such an endeavor. This is where design patterns come in.

This article will discuss the usage of Factory Method [DP107] and Abstract Factory [DP87] as they pertain to developing applications in PHP using object oriented programming techniques.

The first pattern used to simplify object instantiation is the Factory Method pattern. The Factory Method pattern defines an interface for object creation but defers the actual instantiation to subclasses. Take, for example, an application that processes Electronic Funds Transfers (ETFs). There are numerously type of ETFs including virtual check, credit card, wire transfer and so on. Using a non-pattern based approach, the application code requesting an ETF object would need to know precisely what subclass of ETF is needed, and it would need to know the context in which that type of ETF is requested. We would end up with code looking something like this:

switch ($etfType) {
case ETF_VIRTUALCHECK :
$etf = new VirtualCheck();
$etf->processCheck();
break;
case ETF_CREDITCARD :
$etf = new CreditCard();
$etf->chargeCard();
break;
case ETF_WIRETRANSFER :
$etf = new WireTransfer();
$etf->chargeCard();
break;
}

Any time we want to add another ETF, we would have to manually update this switch statement anywhere it appeared. We would also have to update any other conditional code that appears. The CreditCard class hinted at above offers the same problem as the ETF itself in that each credit card type (VISA, MasterCard, AMEX) has its own validation scheme and many types have different numerical formats. We would see a similar switch statement to determine what type of credit card we were dealing with either in the CreditCard class constructor or in the switch statement above creates the CreditCard object.

By implementing the Factory Method, we code our application so it only expects a class that conforms to an interface - that is, it has certain methods and properties that can be uses to submit an ETF and check whether it failed or succeeded. This promote loose coupling in the application because you are not binding a concrete subclass to application code. The result is a great increase in flexibility and maintainablility. It is easy to add new ETF subclasses and implement them because you are not hard coding the application to expect a specific subclass, just a class with a specific interface. Look at this example.

class ETF {
var $data;
function ETF($data) {
$this->data = $data;
}
function process() {}
function getResult() {}
}
class VirtualCheck extends ETF {}
class WireTransfer extends ETF {}
class ETFFactory {
function createETF($data) {
switch ($data['etfType']) {
case ETF_VIRTUALCHECK :
return new VirtualCheck($data);;
case ETF_WIRETRANSFER :
return new WireTransfer($data);
default :
return new ETF($data);
}
}
}
$data = $_POST;
$etf = ETFFactory::createETF($data);
$etf->process();

This is a crude implementation but the intent should be clear. Assume the contents of $_POST represent everything you need for the type of ETF that is happening, including a 'etfType' that says what sort of ETF you are using. This would come from the user making a selection in a form and filling out the correct information. This implementation provides numerous advantages over the first.

1. Data validation can be left entirely to the subclasses and occur without interaction from calling code.

2. Calling code only needs to know of one way to get an ETF object.

3. Creation logic is encapsulated - the ETFFactory decides what concrete class to create based on the contents of $data['etfType']. Calling application code knows nothing of concrete subclasses of ETF.

4. If special measures need to be taken, such as creating a specific type of credit card object, this can take place in one location without the calling application code being involved.

Using this approach consolidates creation logic in a single class - ETFFactory. This eliminates duplication in code when an object is created in multiple locations. With the first method, if a class name is changed or a new ETF class is added, we have to modify the ETF creation code everywhere it appears in our application. With the Factory Method implementation, this is not the case. Our calling application code knows of only ETFFactory and ETF. Subclasses of ETF provide the required specialized behaviors to process themselves in the appropriate way but the calling code needs only to use the process() method.

The Abstract Factory pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes [DP87]. This pattern takes the abstraction displayed in the example above to the next level by providing a common factory interface for a given family of objects. The code that actually uses the factory to create objects only expects an object that conforms to the interface of the abstract factory and does not know any details about concrete factory classes.

Using the example from Design Patterns, consider a game that creates a maze. We have a method that knows what to do to create a maze and it will instantiate all the objects we need to construct the maze - components such as rooms, doors and walls. The example below defines the classes involved - method code is left out deliberately since it is not important to this discussion.

class MapSite {
function enter() {}
}
define('North', 0);
define('East', 1);
define('South', 2);
define('West', 3);
class Room extends MapSite {
var $mapSite = array();
var $roomNumber;

function Room($roomNumber) {}
function getSide($direction) {}
function setSide($direction, $mapSite) {}
}
class Wall extends MapSite {
function Wall() {}
function enter() {}
}
class Door extends MapSite {
var $room1;
var $room2;
var $isOpen;

function Door() {}
function enter() {}
function otherSideFrom($room);
}
class Maze {
function Maze() {}
function addRoom($room) {}
// Etc
}
class MazeGame {
function createMaze() {
$aMaze = new Maze();
$room1 = new Room(1);
$room2 = new Room(2);
$aDoor = new Door($room1, $room2);

$room1->setSide(North, new Wall());
$room1->setSide(East, $aDoor);
$room1->setSide(South, new Wall());
$room1->setSide(West, new Wall());
$room2->setSide(North, new Wall());
$room2->setSide(East, new Wall());
$room2->setSide(South, new Wall());
$room2->setSide(West, $aDoor);

$aMaze->addRoom($room1);
$aMaze->addRoom($room2);
}
}

In this example, we define a MapSite class that will act as a base class for anything that could apear in a maze, such as a door, a room, or a wall. We then define the constants North, East, South, and West to be used for tracking the sides or orientation of these MapSite objects. Following the constant definitions are the definitions for the Wall, Room and Door classes. These objects should be obvious in intent.

The setSide() method of the Room class expects the direction of the side and the object to be placed there - any object derived of the class MapSite. This would typically be a Wall or a Door, but it could support more objects easily. The constructor of the Door class expects two Room objects - the door must be aware of the rooms it is connecting. Next we define the Maze class, which is used to represent our actual maze object in code. We use the addRoom() method to attach rooms to the maze.

Finally, we look at the MazeGame class and its createMaze() method. The createMaze() method creates a maze object, two rooms and a door, then defines what objects occupy the sides of the two rooms and attaches them to our Maze object. At this point, we have successfully created a Maze and put some rooms into it.

Now that you understand the example case, we need to talk about the drawbacks with the implementation used in this example. The main roadblock with using this implementation is that the MazeGame object is hard coded to create specific classes of objects - that is, it creates Maze, Wall, Door and Room directly without use of any factory methods. We can improve this design by refactoring our createMaze method to use a MazeFactory object for object instantiation. Here is an example.

class MazeFactory {
function MazeFactory() {}
function createMaze() { return new Maze(); }
function createRoom($roomNumber) { return new Room($roomNumber); }
function createDoor($room1, $room2) { return new Door($room1, $room2); }
function createWall() { return new Wall(); }
}
class MazeGame {
function createMaze() {
$factory = new MazeFactory();
$aMaze = $factory->makeMaze();
$room1 = $factory->makeRoom(1);
$room2 = $factory->makeRoom(2);
$aDoor = $factory->makeDoor($room1, $room2);

$room1->setSide(North, $factory->makeWall());
$room1->setSide(East, $aDoor);
$room1->setSide(South, $factory->makeWall());
$room1->setSide(West, $factory->makeWall());
$room2->setSide(North, $factory->makeWall());
$room2->setSide(East, $factory->makeWall());
$room2->setSide(South, $factory->makeWall());
$room2->setSide(West, $aDoor);

$aMaze->addRoom($room1);
$aMaze->addRoom($room2);
}
}

This method is significantly better because it moves creational knowledge out of the createMaze() method and into the MazeFactory class. This will work fine if we only want to use one family of Maze objects, but what if we want to create subclasses of Wall, Door and Room to allow different behaviors? The examples given in Design Patterns use enchanted rooms and rooms with bombs as examples.

An enchanted room could have special behaviors, such as requiring conditions to be met before a door could be opened or closed. A room with a bomb would know what conditions caused a bomb to detonate and would track whether or not the bomb had gone off. If the bomb had gone off, it would keep up with damage to walls from the bomb. If we wanted to use these classes, we would have to parameterize our factory object to check some sort of input condition to know which family of objects to create.

This is where the Abstract Factory pattern comes in. This pattern uses the Factory Method pattern to handle actual object instantiation, but the value of the Abstract Factory pattern comes at a higher level. We code our calling code not only to use factory methods for object creation but to expect a factory object that conforms to a certain interface. This means that we can use different factories - all based on a single abstract factory interface - to create different families of objects. Calling code would only need to expect a class that derives from the original MazeFactory class.

For brevity's sake we will not type out the code to define the subclasses of Room, Wall, and Door, but we will define the subclasses of the MazeFactory object that are used to create enchanted mazes and mazes with bombs in them.

class EnchantedMazeFactory extends MazeFactory {
function makeRoom($roomNumber) { return new EnchantedRoom($roomNumber); }
function makeDoor($room1, $room2) { return new EnchantedDoor($room1, $room2); }
}
class BombedMazeFactory extends MazeFactory {
function makeRoom($roomNumber) { return new RoomWithABomb($roomNumber); }
function makeWall() { return new BombedWall(); }
}

We can now use different concrete factory classes to create different families of products - in this case, different types of Doors, Walls, and Rooms. We are now left with one last problem - createMaze(), at last glance, is hard coded to create a MazeFactory object. Since createMaze() only needs to create the objects themselves through a standard factory interface, there is no need for the method to ever actually create the factory. We should pass the factory in as an argument to createMaze() and then let the method do its work.

class MazeGame {
function createMaze($factory) {
$aMaze = $factory->makeMaze();
$room1 = $factory->makeRoom(1);
$room2 = $factory->makeRoom(2);
$aDoor = $factory->makeDoor($room1, $room2);

$room1->setSide(North, $factory->makeWall());
$room1->setSide(East, $aDoor);
$room1->setSide(South, $factory->makeWall());
$room1->setSide(West, $factory->makeWall());
$room2->setSide(North, $factory->makeWall());
$room2->setSide(East, $factory->makeWall());
$room2->setSide(South, $factory->makeWall());
$room2->setSide(West, $aDoor);

$aMaze->addRoom($room1);
$aMaze->addRoom($room2);
}
}

Now in our createMaze() method, no assumptions are made about the type of factory we need. Some other code that is responsible for figuring out what type of factory to create would actually instantiate the MazeFactory and pass it to createMaze(), as in the following example.

$game = new MazeGame();
$game->createMaze(new EnchantedMazeFactory());

After all is said and done, we have created (with a little help from Design Patterns) a very flexible set of classes for producing mazes. It should be noted that in an actual implementation, createMaze() would be using data of some kind to determine what components are required in the maze and the method calls on the various MapSite objects would not be hard coded as they are in the example.

The Factory Method and Abstract Factory patterns allow us to build a great deal of flexibility into our applications by abstracting the process of object instantiation and by helping consolidate creational knowledge in the appropriate classes. The Factory Method pattern teaches us how to use methods for object creation rather than directly instantiating objects through client code. This lets the factory method itself do any work it needs to do in creating the object - work that could involve contextual considerations or initializing certain resources in the object. The Abstract Factory class teaches us how to create groups of related objects with a common interface, creating client code that expects neither a specific type of object nor a specific type of factory.

One of the most important concepts in good object oriented design is "design to an interface, not an implementation." What this means is that you should code your application to expect standard sets of object behaviors but not to expect specific object types. This results in a system of objects that know as little as possible about one another and, so long as the interfaces to these classes do not change, the internals of the classes can vary without adversely affecting other classes in the system.

In the final createMaze() example above, we see this in action on two levels. First, we pass any MazeFactory type object to the method, which is used to instantiate various MapSite objects and load them into a Maze. Second we are working with the Maze and MapSite objects without worrying about their specific class, just their interface - we know a Room needs a room number when we create it and we know we can enter a room. It does not matter to the client code that the room may be an EnchantedRoom or a RoomWithABomb - all it needs to know is how to create it and how to use it. This is the very definition of programming to an interface. The opposite case is true with the first maze example where createMaze() directly creates specific Room, Door, and Wall objects.

The use of these two patterns is a good starting point for programmers just beginning to learn about patterns and good object oriented design. This is the first in what will be a series of articles on design patterns with PHP examples and is intended for developers who are somewhat new to design patterns. Thanks for reading and please don't forget to leave some feedback in the comments section!

(www.devshed.com)

LIMB - Access policy basics

nospam@example.com (chnghia) — Wed, 21 Dec 2005 11:26:19 +0100

Limb 2.x has 2 tier permission system

Object access: The access system determines the user's permissions for the requested object: read, write or both.

Actions access: The access system determines whether the user is allowed to perform the requested action over the object.

These steps are sequent and tightly connected. An action requires a set of ObjectPermission to be accessible by user. So it's not enough for a user to have an ActionAccess only - the user must have specify permissions for the requested object too. Sounds a bit complicated, a good example should make everything clear hopefully.

Limb uses only resolving (postive) access records. So user accumulates permissions from all the groups he participates in with his own permissions. Currently there is no way to restrict any user to have access to some object if any group that user participates in has access to that object.

Object access

In Limb 2.3 we have simplified our access policy a log. We have removed read and write permissions separation. Now user can just have access to an object or not. If user doesn't have permission to get access to an object then in most cases the user is not aware of the object existence at all. The only possible way to see such objects is to directly use site_object::fetch() method.

You can browse and set user permissions (group based) for objects at with Limb GUI using /root/admin/objects_access page.

Actions access

Action is a set of some operations. Defined in the site object controller actions may apply to the site or ... perform whatever you need. To perform an action the user must have a permission to execute it.

Limb provides a GUI to control action access at /root/admin/controllers (/root/admin/classes in Limb 2.2.x) page. The administrator sets what actions are accessible by user groups. As mentioned above Limb doesn't has a GUI to set actions permissions for individual users. We have not faced any case that required such functionality in our practice so far, yet it's not a problem to implement one.

Each action requires the certain set of object access permissions described in the site object controller. Lets look into one small example to make everything clear:

Small example

Suppose we have some article_controller. It supports only 2 actions: display and delete:

class article_controller extends site_object_controller
{
    function _define_actions()
    {
        return  array(
          'display' => array(
           [[...]]
          ),
          'delete' => array(
           [[...]]
          ),
        );
        
        parent :: site_object_controller();
    }
}

Ok, lets imagine we have 3 article objects in out system: article1, article2 and article3.

Our user is a member of 2 groups: visitors and admins.

Objects permissions that user groups have for objects are:

            article1   article2   article3
visitors               ok         ok 
admins      ok         ok

And user groups actions access as follows:

            display        delete
visitors    true           false
admins      true           true

It means that our user is allowed to display all articles (since the user is a member of visitors and admin groups), can delete all articles.

(limb-project.com)

LIMB - Access templates

nospam@example.com (chnghia) — Wed, 21 Dec 2005 11:11:13 +0100

In some cases we need to set a predefined set of object permissions. For example new article, created by the content manager needs to be verified by the editor in chief before it is published for public view. Hence we need the new article to be created with no access permissions for ordinary user and with full access rights to the editorial staff. Meet access templates!

Access templates is a matrix of the object permissions applied to the object. This a common instrument for the document flow control in Limb.

Weve faced 2 cases of using access templates so far:

applying acces template from parent to child
applying access template for object itself

Limb provides a GUI for setting access templates at /root/admin/controllers/. See Set access templates action.

access_policy class resolves all issues, connected with getting or saving access policy for the particular object.

class articles_folder_controller extends site_object_controller
{
    function articles_folder_controller()
    {
        $this->_actions = array(
                'create_article' => array(
                        'action_path' => '/article/create_article_action',
                        'action_name' => strings :: get('create_article', 'article'),
                        'can_have_access_template' => true, //note this attribute!
                ),
                'publish' => array(
                        'can_have_access_template' => true, //note this attribute!
                        'action_name' => strings :: get('publish'),
                        'action_path' => '/doc_flow_object/set_publish_status_action',
                ),
        );
        parent :: site_object_controller();
    }
}

For example, in case of creating a new article create_article appropriate action tries to create an article_object and to apply access permissions as defined in the access template. If there is no access template for this action (e.g. its empty) then access permissions are copied from the parent object. When publishing an object access permissions are applied to the object itself(access template IS mandatory in this case).

(limb-project.com)

LIMB CMF features

nospam@example.com (chnghia) — Tue, 20 Dec 2005 14:41:08 +0100

Features

Website structure management

Multilanguage support

Users management

Audit trails

Permissions management system

Statistics system

Integrated search engine

Content version control

Navigation management

Multimedia repository

Richtext editor

JIP(just in place) edition

Background Features

Strong OOP development

The WEB in now built mainly on scripting technologies, messing script codes with html. We refused this way of web development from the very beginning. OOP development allows programmers to take full advantage of design patterns, reuse existing code, and create new modules quickly.

Test driven development

The biggest problem in software development is to produce stable and quality products. When programmer makes changes in one module he has to be sure that will not break any other module or the whole system. We extensively use unit testing to make sure all LIMB functionality is stable enough.

MVC pattern design

The "worst smell" in the web development is missing scripting codes and HTML. The best decision is to separate business and presentation logic. Programmers can reuse their source codes in different projects and designers should only care about HTML and happily use their favoriate HTML editors. This all is possible through MVC architecture, where View is represented with excellent WACT templates.

(limb-project.com)

LIMB - CMF

nospam@example.com (chnghia) — Tue, 20 Dec 2005 13:38:49 +0100

LIMB is the first WACT based CMF. LIMB is built with LAMP technologies and utilizes the whole great experience of Open Source software development.

The main aim of LIMB is build scalable, extensible and easy-to-update Content Management System (CMS).

LIMB uses its own unique way to organize website's content with flexible object metaphor: "Every piece of information is an object".

LIMB introduces JIP (just in place) managing feature. JIP creat/edit/delete modes allow dramatically decrease time of learning the CMS and simplify the administration rountine.

(www.limb-project.com)