Goodbye MOO welcome POODLE WCMS!

Some already know about MOO CMS and what the cvs sources are all about. It is dynamic fast and full of libraries.

However, after extending and integrating in some websites I also found its limitations and lack of dynamics. So, with my 10 years of PHP webdevelopment experience i've decided to stop this project in its beta stage (of 5 years) and start over (without abandoning all sources).

The new project name is POODLE WCMS (PHP5 Object Oriented Dynamic Libraries Extended Web Content Management System).
What a WCMS is all about can be read at Wikipedia.

Resources

After reading and learning about the WebDAV principles i found out that MOO CMS is almost identical and that WebDAV would be the conform way to design a system instead of keeping a similar system. By using WebDAV it can extend in any way someone wants and be better organized then currently is available in MOO.
The difference is that MOO had "pages" while WebDAV talks about "Resources" where a resource can be anything (graphic, document, html page, iCAL calendar object, etc.).

POODLE will have a table with "Resource Types" to identify each resource. A resource type can be anything from a comment to a html document and either a visible or hidden type.

example

There can be resource types like: user, vcalendar, vtodo, comment
A vcalendar resource is a child of a user, indicating it is a calendar of user "Stimpy".
Inside the vcalendar it has some vtodo resources indicating "Stimpy" has some things todo.
Each vtodo may have comments from "Stimpy" or any other user

User "Stimpy"
- Calendar "Project X"
  - vtodo "write documentation"
    - comment from "Ren": "Don't forget screenshots!"
      - comment from "Stimpy": "Oh, joy!"
    - comment from "Powdered Toast Man": "Leave everything to me!"
  - vtodo "call Ren"
- Calendar "Project Y"
  - vtodo "write documentation"
  - vtodo "call Ren"
    - comment "called Ren"
- HTML page "My Weblog"
  - BLOG item "I forgot an image..."
    - comment from "Ren": "You eeediot!!"

Each resource type has a mime type to identify the kind of content. Basic content types would be: XML, XHTML and Text.

Dynamic Library Extending

Thanks to PHP5's autoloading system it is easy to load libraries and classes on-demand.
My current source supports Poodle, Zend and Pear libraries which makes it very extensible.

ECMAScript + DOM

POODLE will become available with its own JavaScript framework in KISS principle.
It mainly fixes Webbrowsers lack of:

DOM support (mainly for Internet Explorer 7 - 8):
HTML5 elements
custom events
IE proper event simulation
IE garbage collection (memory leaks in Internet Explorer)

It extends any web page with:

Simple extensible AJAX
HTML element resizer
MSG box element to show success, error and information boxes
WYSIWYG with syntax highliting

Template system?

Yes, there is. It's based on Zope's TAL (Template Attribute Language) and parts of XSLT.

It is not PHPTAL. Instead, it uses the PHP XML parser and some code to handle the TAL attributes.
By using the XML parser the markup language code is checked to make sure that it is valid.
You may even load a DTD list to report deprecated tags and deprecated/unknown/missing attributes.

Some XSLT tags are supported, currently they are: choose, for-each, if, otherwise, value-of and when.
Why? Well, some people are familiar with TAL and others with XSLT.

No other scheme is supported untill they are properly found by the XML parser.
For example, phpBB won't work as it uses  which is dropped at parsing.

Learning curve for developers?

KISS: If you know PHP you know POODLE!

With that said i will explain it a bit...

SQL object has the same methods as the PHP MySQLi extension (and more).
SQL Results are similar to MySQLi results but, extended with ArrayAccess, Countable and Iterator.
Example: foreach ($SQL->query('SELECT * FROM table') as $record)
$_GET, $_POST and $_FILES are converted to extended objects (ArrayAccess, Countable and Iterator) with type casting support.
You can still access $_GET['var'] but also force the type like $_GET->int('var') or $_GET->txt('var') (strips html)
Image objects have the same methods as the IMagick PECL extension but not limited to IMagick (GD and netPBM are also supported)

Due to this kind of object extending you don't need to learn new methods and ways to do the same task as you normaly did. The only difference is that you do the task thru objects.

When available?

I still have to write a good documentation how the system will finally work and resolve the glitches. When that is ready the actual building of the system will start.

UPDATE 2010-07-24:

Base parts of system are getting there. I use the "setup" system for testing the library base components.

Here's a screenshot including a JavaScript based PHP debug tool!
It shows (in order): peak memory usage, parse time, template parse time, warnings/notices/deprecated, included files, declared classes and declared interfaces

UPDATE 2010-08-27:

Output and Resource handling are finally getting some structure and i really like the outcome so far!

The structure is actually pretty simple when you get the hang of it.
Every URI is a 'resource' which has a resource_type_id.
When the resource_type_id=0 then it's a simple Poodle_Resource_Default object, else it's the object as specified by resource_type_class.
Then you output the body with: $POODLE->OUT->display(REQUEST_URI, 0, $resource->body)
Now the system automagically ends the output with $POODLE->OUT->finish()

UPDATE 2010-09-20:

I'm going to structure a login/register system with authorization provider schemes.
In short: just 1 login field (no password) that will detect what kind of user you are.
For example:

If you fill in your gmail email address
Poodle detects if an account exists with your google ID
NO or YES + Authorization Provider: Poodle will forward you to the OpenID login of google.com
YES + No Authorization Provider: Poodle will ask for your password

So, if you don't want OpenID you can just register manually with your gmail and at login the system will just detect if it should ask for your password or redirect to google.
It will not be limited to OpenID providers (like: google, livejournal, etc.) but, can be extended with other schemes like: i-names, ldap, imap, etc.
This will be done through the auth_providers database table with regex matching on the provided login uri.
Basically something like this:

id	provider	regex
1	database
2	imap	(.*)@example\.org
3	OpenID	(.*)@gmail\.com
4	OpenID	(xri:/)?[@=](.)
5	OpenID	www\.myspace\.com/(.*)

UPDATE 2010-10-24:

Finally the authentication/login system is ready. Currently it supports Cookie, Database, OpenID and XRI.
Below is a preview of a bar with login form. Simple, isn't it?

UPDATE 2010-11-21:

Figuring out how to manage resources through the Administration interface. One way is like other CMS's, by using a list of posts/pages. This doesn't feel right as it doesn't show you the path structure. Instead, i wrote a "tree" using unordered lists with a bit of XHR (XMLHttpRequest/AJAX). Tree default state
Tree unfolds using ajax
Tree unfolded
Of course this tree becomes very big when the site grows, so a "default" like the other CMS's should also be made with filters and ordering.