Forumlar / Cotonti / Core Labs / Archive / CMF for Cotonti

Intro

Cotonti is constantly growing. Siena will be more modular and it will provide various APIs for different aims which were previously achieved by hand-scripting, hard-coding or not achieved at all. These are still mostly core-related, so we like to keep them short and clean.

Meanwhile the web industry has changed a lot and pure CMS are quickly loosing their positions in the developer world. Custom applications should be built rapidly, more reusable components are required.

The question is not if Cotonti needs a CMF, the question is what CMF it needs and how tight they should be integrated.

CMF synthesis

Well, Cotonti comes with some CMF features:

• clear structure
• database abstraction layer (not such a good one)
• template engine
• internationalization
• authorization management
• configuration
• cache
• debugging tools
• URL rewriting
• form generators
• pagination
• validation (could be more verbose)
• AJAX helpers
• security tools
• and more.

What it misses as a CMF is:

• controllers
• CRUD (create/retrieve/update/delete behavior for basic entities)
• ORM
• routing (rather than just URL rewriting)
• putting it all together in pure OOP

Existing CMF

There are loads of CMF systems, but keeping Cotonti principles in mind, the choice is very simple because it must be

• Fast (bye-bye CakePHP, Symfony)
• Lightweight (bye-bye ZendFramework)
• PHP5 (bye-bye CodeIgniter)
• BSD/MIT/Artistic license (bye-bye Doctrine ORM)
• Stable and large community support (bye-bye Doo)

This is how I have come up to Kohana and Yii. But Yii uses components and widgets much like Prado, so it very far from what we are used to with XTemplate. Kohana appears to be more flexible.

Own CMF

I've been working on reusable OO components for Cotonti for year by now, it's mostly CRUD/ORM and some behavior common to many Cotonti modules and plugins. I've completed several projects using these libraries, but I can't get rid of the feeling that it's still a lot of work to do which is just reinventing the wheel.

The only true reason of continuing work on an own CMF is that Cotonti really has its own spirit and its own code practices, which will be broken if building on top of some other framework.

Rebuilding everything with some CMF

Thinking it over realistically, it's nonsense. Why? It will take 6-12 months just rebuilding without any new features being added and a lot of new bugs introduced. Which is suicide.

Using Kohana (or something) for module development

I'm experimenting with it these days. To be exact, it's Kohana3 I'm experimenting with because I like HMVC and some other things in v3. The problems I have encountered are:

• Routing is hell when trying to get Kohana work on a Cotonti site
• Directory structure is very different too
• Probably Views should be completely different (XTemplate) from what Kohana comes with, but it's not a big problem because Kohana is flexible at this point

Considering Kohana integration, there are 3 different ways of doing it:

1. Each module as a separate Kohana application
2. All Kohana modules as a Kohana appilcation
3. Built-in Kohana components in the core

These are my thoughts for now, share yours.

@Trustmaster:
Rebuilding or integrating a lot off stuff on an other base is madness (time wise)
You will be always far behind off the competition... (if you see it like that)
I think Cotonti should keep following its own path... BUT we do need more sexy stuff in the UI.

I have been programming a LOT of years now and found that OO is NOT the holy grail.
(Have done it in some languages like C++).
That doesn't mean we should not use it. In fact for some parts it will be nice if its there.
I have always found that clear/clean structure and good code libraries are effective enough and in the end more flexible/adjustable. (A fact is that newbies think it is less sexy)

My thoughts:
So maybe all these "new" techniques and stuff is not always "The HOLY Grail".
Only one thing is HOLY and that is a clear and easy to use userinterface.
====

Maybe it is better to concentrate on the stuff that people really want.
(We should make a priority list off that !!!)
In Cotonti I found that a lot off stuff is happening but not always in the visible areas...
For end users (not programmers) this is what matters the most.

e.g.
nicer looking PFS, Draft versions off articles, sexy galleries and image stuff.
Some nice looking templates for businesses, blogs

I must say, rebuilding Cotonti on top of anything is not an option, it's a suicide.

Somehow, we need to keep the original idea and spirit of lightweight easy scripting. That's why the core must be minimalistic and procedural. But I find objects extremely useful for business logic (and model-driven applications), that's why I propose having (an optional) OO framework for rapid business-related module development (e.g. I use it to build project management software on top of Cotonti).

As for CMS/CMF decision, there is a class of systems which has both: Drupal, Silverstripe, MODx 2, etc. So, we are not forced to become either CMF (which is clueless, there are enough good solutions) or just a CMS (which would kill the spirit of unleashed customizability which we still have).

So far I see it like this: we'll continue improving our lower-level procedural APIs, making them more like a CMF, but quite minimalistic. For those who wish to write modules/plugins in a OO fasion, there will be an OO framework which lays perfrectly on our procedural underlayer. This optional OO overlay will be either our own, or some components (like ORM) will be reused from other projects (e.g. Kohana). But in general, I'd like to keep existing model which I call MVS (Model-View-Script!) rather than following the Rails MVC which the web has gone mad about.

I just wonder is this is interesting:
http://ezcomponents.org/

Also, as for OO... I have messed a bit with eZ Publish cms and I really liked their content management. It's something like our custom fields, but with several additions:

- each custom field type has it's own mini-template depending on the content. A textarea field would have a mini-template with simple textarea html block, but e.g. a "flv media" custom field (used for storing the path to media file) would have a template with a html flash player code. The mini-templates would have two versions: one for page.php and one for list.php

Those mini-templates get automatically included into a skeleton template of a page (or other content type). Our page structure is like title, subtitle, text, - eZ Publish approach is much more flexible. Without any need to write a plugin, we can extend a page, adding there more data fields with their own representation mini-template. Now we just include a tag and display raw data, something like I describe is only in page.add and page.edit templates.

(I think I can make a plugin that illustrates this idea.)

Also, we have only "page" content type. Ez publish allows to define more content types, like e.g. "blog page". In this process we define the skeleton template for it (we can copy the skeleton template of page), and define the data fields used (with their mini-templates) and their order (like title, subtitle, text, podcast field->displaying an mp3 flash player). In eZ we can even create a content type "contact form" and add there data types of several input fields and a textarea.

This functionality could do wonders without much coding. Now if we want to have something extra, it must be a plugin. With the above system, somebody could even make a gallery if he was stubborn enough, making a content type "gallery page", adding three data fields: title, image, description, and voillea: the fundamental image showing page is ready. Several such "gallery pages" in a category list would make a simple gallery category (remember that there are also data type mini-templates for list.php).

I encourage you to install and try eZ Publish to see it. However, eZ Publish is a bull full of code and I don't like its exagerrated complexity (like their own template language). Anyways, I'm sure that this content type management can be achieved with less effort.

For this content system, I would only see additionaly the change in PFS and change in Auth system (per-user permissions). It's neccessary since if the data fields are about to show the files, the files must be saved somewhere.

Oh, so it's called taxonomy? The first time I encountered "taxonomy" was Drupal, and I didn't understand a thing - I thought it's rather the hierarchy of categories.

Drupal was strange. eZ Publish was easier to understand and maintain.