We already have a large number of CMSes - what

I would first answer, because ALOYS CORE is not a CMS.

No, w/o joke. I'll go a little on historical point and after on technicals
points.

The evolution of Dynamic programming had a quite interesting devloppement,
and you can quite follow it by the parallel changes on a language like PHP.
The first times where only templating help. They grow up to display dynamic
content. Then was the time of the multi script apps that were dedicated to
some purpose as remain most of the forums app, for example. I would call it
the dynamic explosion.

The CMSs arrived on OS world with the idea to rassemble all this various
applicative functions in one program. Slashdot give a big push on this idea
followed by Nukes. I would call it the sites explosion.

Here a conceptual change was necessary. Maintenance, version shift was not
possible anymore or difficult in a per page php file structure.
Some responses responses where given. Simplifying the application intended
to make usage easier, say the bloggin and Wikis world. Change the concept to
an editorial way (SPIP like). Big ideas and new concepts comes from here. I
would call it the conceptual explosion.

But a real improvement was module design. So the page structure was managed
by the CMS and particular application by the module. Large number of modules
where created.Due to the success the same problems arose. Base product
changes made multiple modules changes necessary giving huge overhead of work
to site managers and module writers. For the worst side, lot of various and
quite the same flavours of the same modules grow. This was the time of the
modules explosion.

As a program grows bigger and bigger, it is difficult to change the inner
concepts apart trowing the whole thing to trash and rewrite over new
concepts. Not to say there was big resitance. Big CMSs response was API to
hide the inner structure, but due to historical reasons it was often like an
'empltre sur une janbe de bois' and remains heavy and not always obvious to
use as API was created on CMS and not the contrary.

Anyway CMS is quite easy to program and lot of poeple begun to be able to
write their own. They often do in response to bad design problems or inner
function lack. This was the time of CMS explosion. In fact we always are in
this time, as you noticed :'We already have a large number of CMSes'.

The interest of this period, is that freed of historical backgroud, lot of
inner functionalities were created. Templating system, XML db storage, XML
presentation, LDAP storage, multi-db abstraction, SOAP data transfer, and so
on. And as usual there was a difficulty. reinvent the wheel on each CMS.

Here comes the framework concept. As I saw coding here and there, most of
the concepts comes from java. The idea is why not consider CMS, KMS, and al.
as distribution of a skeletton giving the whole background tools. That was
the framework explosion. Zope is for example, of this time.

Well, ok. But now we have huge apps full of various concepts. During all
this time PHP envolve, giving programmer some OO possibilities and some
discover it was possible to create REAL OO classes, the only thing was to
make it in some 'tricky' was, but it was possible. And Zeev Suraski's
anounce of php5 OO concepts make lot of programers salivate (even if a lot
cannot follow, it makes 20 years I follow OO concepts developlments, and 20
years I see poeple keeping structured programming in OO clothes). This will
be the OO explosion. And I think a lot of classes packages will be delivered
as standard packages as PEAR (even if it's not always the best OO design,
the less to say, but a lot of young poeple will shake our old barbs, and i
think we'll laught a lot un in a short time remembering all these old good
days...)

Here comes ALOYS CORE. It is not the sole on the way, but make it his way.
You can see Ismo for example, and Ampoliros, and some others. Let's go into
some technical :

Taking all the concepts we've got we can break the whole things into short
functionality class familly. Aiming a 3-tier, well in fact n-tier structure
as a goal, it's quite simple. I give the present state of concepts
devlopement not the present code structure, it's in full writing process,
the why of the pre-alpha status.

database layer (say outer datasource/dest):

-dataSource classes : manage 'physically' data. It can be DB, SOAP, mail,
directory of files, XML File, whatever...
-dataInterface classes : (gives general API to data) enableing base
functionality on dataSource (create, modify, delete, read, connect, ...)

business layer (application layer):
- dataStructure classes : gives access to data in the business layer. It
manage the dataInterface but is seen by the client as a data structure, so
client has not to bother with data implementation details
- module classes : Gives base class for modlet or portlet dev, in fact
that's the only thing remaining of the old module concept. In my present
concept module is a package of modlets, and packages are stored in module
directories, many packages per directory.
- widget classes : This is the app. level interface to inner structure of
data structure. It manage transformations, verification, initialisation of
inner struture of a datasource, say the field level. It's inner desription
of dataStructure.
-environment classes : This is the appl access to all configuration, state,
data input stuff. These are for example Request, User, Session, Variables,
Cookies, ML strings, etc.
- dispatcher classe : This class named Aloys is the director of all the
execution of the stuff. It calls modules classes according to environment.

presentation layer :

- templates classes : this is the process that transform dataStructure to
client dataStructure. For example, HTTP, HTML text, of XML, or RSS, or
whatever. Client could be another program and server only a redepository of
data and processes, why not.

CORE classes are intended to keep the shortest and the simpliest possible,
so I've not a lot of functionality. Before going to ALOYS CORE CMS level,
just an example of core usage.

hello world app :

We have a main program : index.php

incl('classes/environment');
incl('classes/aloys);
$aloys = & new Aloys(new Environment);
echo aloys->exe('default_default_main', 'this');

We have a package : modules/default/default.php
as we still in php4 we have to put some constructor, but as intended to be a
PHP5 (when it comes) it would be so:

class default_default extends module
{
modlet_main()
{
$this->set('text','Hello world');
return true;
}
}

We have a template : modules/default/templates/this.html
We use here TemplateHTML base class as standard for presentation layer.

<?php echo $text;?>

But all this is stupid, and overwork. It's like using assembler to display
window in windowing environment.

Here Comes the ALOYS CORE CMS level. It's not part of ALOYS CORE but just an
example of implementation of it. And you can have as many implementation as
you want. This layer derivate the core classes to give base functionalities
to the end user. In ALOYS CORE CMS implementation we have.

- index class - module derivated. this class gives all creation,
modification, multiline modifiocation, deletion, and display for a module on
a datasource.
- block class - module derivated. the is base class for blocks display, it
gives basic block display on the datasource for a table.
- admin class - module derivated. As said by the name it gives access to all
admin functions for the module and datasource. Definiing the widgets used by
fields, module variables, module string, etc.
- access class - dataStructure derivated. This is the datasource for the
module. It gives the base additional data for the datasource, links to
functionality on rows (create, delete, modify, display details).

Keep in mind that only an example implementation you can derivate all the
things you want. But in fact, now if I have a table 'example' I can directly
create a package 'index' in 'example' module directory :

incl(core/index);
class example_index extends index
{
}

and I have the complete example management. The only things I have to write
is supplementary modlets. and in the shortest way possible.

There a lot of things more to say : access control system, dynamic widget
creation, dynamic module creation, etc.. but this whole thing is beeing
written and It's so much work. You can alreay see the roots on
www.doc.aloyscore.com but the whole structure is changing, and I integrate
ideas each after the other, the concepts I described here is already a few
steps ahead of ALOYS CORE implementation. I let the curent stable branch as
an example of the basis concept for programmers.

basis facts for ALOYS CORE intentions :
full OO php5 complient.
datasource independant (not only DB)
Output style independant (not only templating system)
KISS development
Maximum reusage of classes, keeping modlet developement as short as
possible. If I write a news module base on a DB datasource, I want to be
able to use the same package with a mail datasource w/o any programming
change... (some work more now, but bases concepts have been tested, it
works)

I hope I explain you well that it's not another CMS, in fact it's a
framework for any web aplication and even non-web application...

Sorry for my bad english, I hope it didn't made my ideas unclear.

Have a good day

George Kilroy
http://aloyscore.com