New WACT powered CMS: LIMB!!!

[pachanga]

Hi!

We have at last published our demo version of LIMB - new WACT powered CMS.
You can find it here: http://demo.limb-project.com

We've been developing LIMB for 1.5 years already and only now we have a strong feeling about its almost functional completeness and stability.

We're currently working on establishing LIMB support site and basic collaborative tools on sourceforge. We're going open source!
You can download it from http://sourceforge.net/projects/limb/
(Use it on your own risk!!! Tests are not included yet)

Please feel free to browse demo site and leave your comments and critique(if any) here or via mail: limb at 0x00 dot ru

Below is the VERY brief description of LIMB.

* LIMB follows MVC pattern, in fact, we have our own Model and Controller components, however,View is WACT based. From WACT we have only templating subsystem.
WACT templating subsystem is very inspiring and excellent piece of code...unfortunately, we had to
almost totally rewrite it for our specific needs.
We have our own tags, only about 20% originally from WACT.
Our next major release has plans to use WACT as an external package and we DO plan to collaborate with WACT developers, if they agree.

* LIMB metaphor is very simple just like this: "Every piece of information is an object".
Sounds not too amazing these OOP days? Well... ALL LIMB domain objects(site objects in LIMB terms) are stored in the single tree(EZ has something alike). Client request is mapped to the objects tree and required object if found is fetched.

* LIMB object metaphor allowed us to erase the line between front-end and back-end, you're able(provided you have neccessary security level) to handle resource content directly in the place, may sound unusual but it's woth of seeing We call it JIP - Just In Place editing.

* LIMB has flexible access control. Every site object is active, it has a set of actions registered in the access system.
User is allowed to fetch objects according to his security level.

* LIMB is end user friendly! We do believe that end user interface experience is very important.
We heavily depend on the client scripting, this seems to be quite stable with DOM. However IE is a currently preferred browser.

* LIMB core is about 90% tested with Simpletest, we extensively apply XP(TDD assumed) where it's possible.
However we DO lack of experience in the field of testing Hey...but at least we try.

Ok, enough of singing praises... LIMB is still very BETA and immature(did i mention 'functional completeness'? ) speaking in terms of public usage.
We do admit this! We don't want to be isolated anymore, being isolated for a small company is a dead end
We want to contribute to PHP community and seek for professional developers help.

P.S. LIMB CMF support site is on-line at http://limb-project.com

[sweatje]

Sounds cool. I look forward to investigating

[Widow Maker]

I'm also listening

Every site object is active, it has a set of actions registered in the access system.

This part I'm thinking, if you can clear it up for me, is that you'd create (automatically ??) all the required objects to each given action if and when required ?

Some benifits are obvious of course, a bit silly of me of not thinking of this one myself though

ALL LIMB domain objects(site objects in LIMB terms) are stored in the single tree(EZ has something alike). Client request is mapped to the objects tree and required object if found is fetched.

Some more details and an example or twelve would be welcome

Thanks for bringing this up btw.

[ghurtado]

I just found out that by visiting the demo site and clicking around for a few minutes, I immediately got a much better understanding of the system than any explanation could give. I suggest that you guys do just that, its worth it!

I am very impressed with what I have just seen LIMB do, its very straightforward, I love the self-contained templates, the JIP, in-place content editing, everything! It is a very nice piece of work in my opinion, and the interface is very well thought out and provides for very smooth user interaction with the CMS. I can't recall seeing many CMS's that were nearly as user-friendly or clean designed.

Congratulations on LIMB, all I can say is "well done"!

[Selkirk]

We have at last published our demo version of LIMB - new WACT powered CMS.

Very impressive. I like to see examples of non-trivial applications that use WACT.

It looks like you've taken a little different direction that I have. Most of the stuff I have uses a template helper class, while you have moved this functionality into the templates with custom components and tags in the template. Its nice to see alternate ways of doing things.

we had to almost totally rewrite it for our specific needs.
...
Our next major release has plans to use WACT as an external package and we DO plan to collaborate with WACT developers, if they agree.

Sounds good to me. I would like to hear about what caused you to do the re-write.

We heavily depend on the client scripting, this seems to be quite stable with DOM. However IE is a currently preferred browser.

Unfortunately, the rich edit control doesn't work under Safari or Firefox on the Mac and there is no fallback option. I can't login to the demo right now to test (somebody changed the admin password?), but I can tell you from experience that the rich edit control won't work on IE Mac, either. None of the forms that have a rich edit control on them will function on any of the current Mac browsers.

I am looking forward to taking a closer look at the demo when I have a Windows machine available.

[cyngon]

I wasn't able to test the demo functionality. After clicking the login link at the top, I was brought o another login page with "admin" filled in as the username and entering the password "test" didn't work.

Any idea what may be causing this?

[Fleeters]

i was also not able to view the demo. what the?

[tonyskyday]

It worked fine for me, though I didn't poke around too much.

[pachanga]

I wasn't able to test the demo functionality. After clicking the login link at the top, I was brought o another login page with "admin" filled in as the username and entering the password "test" didn't work.

Any idea what may be causing this?

Well someone changed the password, we're working on making admin, test to be unchangeable. It will be fine in few hours. There're still some malicious users out there Cron does it's refreshing job every hour - sorry for this

[pachanga]

Unfortunately, the rich edit control doesn't work under Safari or Firefox on the Mac and there is no fallback option. I can't login to the demo right now to test (somebody changed the admin password?), but I can tell you from experience that the rich edit control won't work on IE Mac, either. None of the forms that have a rich edit control on them will function on any of the current Mac browsers.

I am looking forward to taking a closer look at the demo when I have a Windows machine available.

Hm..it's strange...richedit should fallback gracefully on the unsupported platforms. That's why we need developers help! We're "windows" guys...yet linux support is the primary task!
Anyways we're planning to make a simpler version with wiki tags support or something alike.

Again i'm sorry about the login problem, system is wide open now, we're solving this problem currently.

I'm making a bigger review of the system, will be posted a bit later.

Thanks!

[pachanga]

Guys, please give me good links on open source collaboration and project management. I'm such a newbie in this field

[pachanga]

Very impressive. I like to see examples of non-trivial applications that use WACT.

It looks like you've taken a little different direction that I have. Most of the stuff I have uses a template helper class, while you have moved this functionality into the templates with custom components and tags in the template. Its nice to see alternate ways of doing things.

Sounds good to me. I would like to hear about what caused you to do the re-write.

We'd been developing LIMB for quite a long time already when we accidentally stumbled upon WACT(it happened somewhere the beginning of december 2003 and we already had our own Model and Controller components). WACT wasn't released yet and was available only via CVS. We were impressed!!!
The idea was totally overwhelming and fresh! EZ and Smarty really smelled bad for us and our own template engine was too simplistic So we checked out WACT and began figuring out what parts of it could be re-used... It turned out that only template system was applicable to LIMB as a View component.

Our application design is quite different from WACT...so we had to code our own tags and components.
Writing custom tags&components for data retrieval every time(like <user:USERS_LIST ...>, <catalog:CATALOG_CONTENTS ...>etc)seemed inefficient for us, that's why LIMB uses conception of datasources, there're several generic types of them. So as you've noticed already our templates are active, however in LIMB it's also possible to reach template components from controller(it's rarely used though).

The idea with datasources seemed also attractive because it somehow reminded us Delphi with draggable form components. In fact it becomes theoretically possible to apply WebMatrix and alike tools...Harry Fuecks mentioned about this somewhere.
Furthermore our site objects model and datasources were a perfect match!

A small example(can be found here):

1 <fetch:SUB_BRANCH target="articles">
2	<core:PARAMETER name="loader_class_name" value="article">
3	<core:PARAMETER name="path" value="/root/articles">
4	<core:PARAMETER name="depth" value="-1">
5	<core:PARAMETER name="limit" value="2">
6	<core:PARAMETER name="order" value="modified_date=DESC">
7 </fetch:SUB_BRANCH>
8 
9 
10 <grid:LIST id="articles">
11 <table width="95%" border="0">
12 <grid:ITERATOR>
13 <tr> 
14	 <td>
15	 <a href="{$path}">{$title}</a>
16	 </td>
17 </tr>
18 <tr> 
19	 <td>
20	 {$annotation}
21	 </td>
22 </tr>
23 </grid:ITERATOR>
24 </table>
25 </grid:LIST>
26 <br>

This one fetches site objects from /root/articles branch at unlimited depth(all our site objects are stored in the single tree), allowing only 'article' class objects, ordering them by modified_date attribute and setting 2 objects limit.
All basic fetching operations can be done via <fetch:* tags.

Then it passes fetch result to its targets, there's only one <grid:LIST id="articles">. LIMB doesn't have LIST tags at all, all tabular data is displayed only with <grid:* tags.

Much more on this will be published a bit later. Guys, it's Saturday evening already and i'm still working Our detailed objects model description is on the way, hold on a while.

P.S. We fixed the login problem: now demo admin user can't create users and change passwords, apply permissions etc. We only had to tweak his rights a bit.

[pachanga]

I guess it's the very right time to get into some internal details of LIMB.
Some links may need authorization - enter login admin, password test if required.

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 site tree.

The site object is defined with set of different attributes. One of the most important is identifier - with identifier you can reach(fetch in LIMB terms) any site object in the site tree. Actually there're 2 ways of fetching the specific site object:
1 - by the full tree path which comprises site objects identifiers delimetered with /, e.g. root/catalog/TDD/refactoring
2 - by the node id, e.g. root?node_id=92
Both point to the same site object.

There're two types of site objects: simply site object and a content object. The main difference of the latter 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 objects never require any complex O-R mapping and if any the developer is required to resolve mapping manually(next major LIMB release has plans for adopting Propel for this purpose).

Here goes the example of the article content object:

<?php
require_once(LIMB_DIR . 'core/model/site_objects/content_object.class.php');

[color=black]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,
'controller_class_name' => 'article_controller',
);
}
}[/color]
[color=black]?>
[/color] 

Every site object has a controller, it defines what kind of actions the site object has.

In the example above the article has the controller too 'controller_class_name' => 'article_controller', let's take a closer look.

<?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 article_controller()
{
$this->_actions = array(
    'display' => array(
     'permissions_required' => 'r',
     'template_path' => '/article/display.html',
    ),
    'set_metadata' => array(
     'permissions_required' => 'w',
     'popup' => true,
     'JIP' => true,
     'action_name' => strings :: get('set_metadata'),
     'action_path' => '/site_object/set_metadata_action',
     'template_path' => '/site_object/set_metadata.html',
     'img_src' => '/shared/images/configure.gif'
    ),
    'admin_detail' => array(
     'permissions_required' => 'r',
     '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(
     'permissions_required' => 'r',
     'template_path' => '/article/print_version.html',
     'action_name' => strings :: get('print_version_action', 'document'),
     'display_in_breadcrumbs' => false,
    ),
    'edit' => array(
     'permissions_required' => 'w',
     '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(
     'permissions_required' => 'w',
     '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(
     'permissions_required' => 'w',
     '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(
     'permissions_required' => 'w',
     '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'
    ),
);
 
parent :: site_object_controller();
}
}
?>

Please note 'permissions_required' part of the code above. It defines what type of the permission the user should have to the site object to perform this action('r' read or 'w' write).

You can see how site objects access can be manipulated at Objects access page.

You can also define how site object actions accessed by groups. It's done in the popup window, so i can't give you the direct link, ok, proceed to the Objects types page and click "Display groups permissions to actions" at the right of article. You should see a nice popup with the good bunch of checkboxes.

Given this we're ready for explanation of how access system actually works:
1 - access system determines what type of access the user has for the object: read or write
2 - access system determines what action user wants to perform
3 - if this action is allowed to the user's group AND if the user has the appropriate access type for the object determined at 1 then the action is allowed

Currently access control is group based and maybe sounds a bit complicated, yet we have not faced the case where this access system proved inefficient(however we do admit its clumsiness and have plans to make it more flexible and clear).

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

Action is transferred via 'action' attribute of the $_REQUEST, so http://limbdemo.0x00.ru/root?&action=edit&node_id=83 will require the article site object to perform 'edit' action(please note we fetch site object by bode id).

In the 'edit' section of the article controller we have 'action_path' set to '/article/edit_article_action', the controller is going to fire 'edit_article_action':

<?php
require_once(LIMB_DIR . 'core/actions/form_edit_site_object_action.class.php');

[color=black]class edit_article_action extends form_edit_site_object_action
{
function edit_article_action()
{
$definition = array(
'site_object' => 'article',
'datamap' => array(
    'article_content' => 'content',
    'annotation' => 'annotation',
    'author' => 'author',
    'source' => 'source',
    'uri' => 'uri',
)
);[/color]
[color=black]parent :: form_edit_site_object_action('article_form', $definition);
}
 
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'));
}
}
?>
[/color] 

Simply, isn't it?
Also in the 'edit' section 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 can be found here.

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

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're transfered to WACT templates as array datasets it allows us to use all the nice features of WACT.
There's no code generation for site objects yet and this colud be a very nice feature!

...still reading? Gosh...i think that's enough.
We hope to put this and other info on the LIMB support site quite soon(a week or two).

P.S. some UML will be a bit later

[Widow Maker]

One point

There is a lot of data in the array for an Action, isn't there ?

I would (personally) like to see this in a seperate configuration file (PHP INI style, XML etc) for easier editing. Never been one in favour of having large array (or other) structures within classes.

OO Programming isn't what's it's about in this regard as I see it, though in saying that, I'm still interested in learning more, of course

[pachanga]

One point

There is a lot of data in the array for an Action, isn't there ?

I would (personally) like to see this in a seperate configuration file (PHP INI style, XML etc) for easier editing. Never been one in favour of having large array (or other) structures within classes.

Agree...but in the end all these configuration files are to become arrays anyway IMO configuration files is a good thing for the auto code generating.

[sleepeasy]

Off Topic:

One point

There is a lot of data in the array for an Action, isn't there ?

I don't like using arrays for configuration/option purposes, especially when some options are themselves arrays of options... nested arrays are hard to read.

The approach I take is to use what I think could be called the Memento pattern, and just use an object to store the options.

$actions = new OptionsMemento();
$actions->display = new OptionsMemento();
$actions->display->permissionsRequired = 'r';
$actions->display->templatePath = '/article/display.html';
$actions->set_MetaData = new OptionsMemento();
$actions->set_MetaData->permissionsRequired = 'w';
$actions->set_MetaData->popup = TRUE;
$actions->set_MetaData->JIP = TRUE;
$actions->set_MetaData->actionName = strings::get('set_MetaData');
$actions->set_MetaData->actionPath =  '/site_object/set_MetaData_Action';
$actions->set_MetaData->templatePath =  '/site_object/set_MetaData.html';
$actions->set_MetaData->imgSrc =  '/shared/images/configure.gif';
// And so on. 

The OptionsMemento above is kind of "anonymous" or something, i.e. it has no methods and does no validation, however you could of course use a particular object to store each "option set" which could do validation etc.

NB If you expect unexperienced users to modify large array structures to configure an application I would foresee a lot of typo's. I think that would be reduced using the above approach because they can more clearly see the structure of the options... $optionSet->optionSet->option = value;

However, any application that is aimed at non-programmers should be configurable with a shiny-happy-GUI

[pachanga]

I don't like using arrays for configuration/option purposes, especially when some options are themselves arrays of options... nested arrays are hard to read.

NB If you expect unexperienced users to modify large array structures to configure an application I would foresee a lot of typo's. I think that would be reduced using the above approach because they can more clearly see the structure of the options... $optionSet->optionSet->option = value;

It makes sense...but we use auto testing to catch any typos in configuration arrays(it works almost perfect) and arrays work fine for now.

However, any application that is aimed at non-programmers should be configurable with a shiny-happy-GUI

At the moment LIMB is developers oriented. IMHO it's very hard to make a nice and flexible application aimed for non-programmers(yet EZ is an example of such a CMS...but we don't like this approach).
I(personally) think that an unexperienced end user should never hack the code, usually(actually never in our practice) he's happy to see nice and shiny GUI with ability to change predefined set of options.

LIMB is developed with subversion. Guys could you give please decent subversion host providers, so we could open the public account.

Any open source management links are welcomed too!!!

[pachanga]

... Congratulations on LIMB, all I can say is "well done"!

Thanks!!! This is very encouraging

[sleepeasy]

It makes sense...but we use auto testing to catch any typos in configuration arrays(it works almost perfect) and arrays work fine for now.

At the moment LIMB is developers oriented. IMHO it's very hard to make a nice and flexible application aimed for non-programmers(yet EZ is an example of such a CMS...but we don't like this approach).

I(personally) think that an unexperienced end user should never hack the code, usually(actually never in our practice) he's happy to see nice and shiny GUI with ability to change predefined set of options.

Good

BTW I wasn't trying to imply that you were expecting non-developers to edit the array - it was a more general comment, but I'm glad you feel the same way.

LIMB is developed with subversion. Guys could you give please decent subversion host providers, so we could open the public account.

Any open source management links are welcomed too!!!

The only two I know of are Tigris.org and BerliOS. Both are free hosters of Open Source projects and both use Subversion for version control.

BerliOS is a German site, but most (if not all) of the site is available in English aswell as Spanish.

You might find it harder to get your project hosted at Tigris.org because they seem to have very strict guidelines as to what projects are allowed - just read "Tigris.org Community Scope" on the homepage. You can see evidence of this by looking at their rather small project list. Also Tigris.org is the home of Subversion itself. IMHO most Tigris.org projects are of a very high quality mainly due to their strict guidelines.

I'll let you know if I find any more. If you find some more could you list them here also (they seem to be pretty rare so finding one is an accomplishment in itself). I wonder when people will realise SVN is better CVS?

Good luck.

[pachanga]

I'll let you know if I find any more. If you find some more could you list them here also (they seem to be pretty rare so finding one is an accomplishment in itself). I wonder when people will realise SVN is better CVS?

Good luck.

Thanks, very helpful! I know about tigris and their policy...anyway i'll give it a try.

[Widow Maker]

I like the idea of a GUI for editing variables, though this point has to be taken into acount, since it obviously could increase development time for a given application for example.

Another point about this, is that GUIs can become complex, very quickly - very time consuming, and very annoying

On the point of arrays though, I might add I'd proberly only implement them for testing, then once a script has been tested and debugged, move the variables to a configuratioin file at that point

But that's only my personal feelings, since some people don't actually mind using arrays, such as yourself

[pachanga]

The only two I know of are Tigris.org and BerliOS. Both are free hosters of Open Source projects and both use Subversion for version control.

Hm...can't find any information they use Subversion on their sites Only Cvs...
I'll mail them directly anyway.

[sweatje]

might want to look over this thread:
http://www.sitepoint.com/forums/showthread.php?t=164765

also, googled and found these that might be of interest:
http://developer.berlios.de/docman/d...394&group_id=2
http://opensource.oreilly.com/news/subversion_ch01.html
http://www.ibiblio.org/fosphost/exhost.htm (lists BerliOS as the only SVN hoster)

[pachanga]

might want to look over this thread:
http://www.sitepoint.com/forums/showthread.php?t=164765

also, googled and found these that might be of interest:
http://developer.berlios.de/docman/d...394&group_id=2
http://opensource.oreilly.com/news/subversion_ch01.html
http://www.ibiblio.org/fosphost/exhost.htm (lists BerliOS as the only SVN hoster)

Thanks, i was wrong BerliOS seems to be a good candidate...Hm..i wonder if it's possible(good practice) to use SourceForge as collaboration tool and BerliOS as a SVN server?

[sleepeasy]

Thanks, i was wrong BerliOS seems to be a good candidate...Hm..i wonder if it's possible(good practice) to use SourceForge as collaboration tool and BerliOS as a SVN server?

I know BerliOS uses SVN because i used to check out GiFT every other day

Off Topic:

GiFT is an OpenSource FileSharing thingy which I don't use anymore since I got WinMX to work on my Linux box thanks to Wine

Anyway, if I was you I'd register my project at Sourceforge and BerliOS.

Even if you don't use any of Sourceforges services it will stop someone coming along and starting a project with the same name as yours.

(LIMB is a cool name BTW)

Not very likely I know but it could happen.