Suffering from CMF or Zend + Doctrine. Part 1

Attempts to create your own system began a long time ago (I think this is familiar to everyone). Over the past couple of years, the circuit on its system has been rolled back, but the system itself has safely rested in the Bose. If there were attempts to somehow use Zend as components, then in the end it was decided not to reinvent the wheel, but simply to take Zend as the basis.
Zend - 1.8 / Doctrine - 1.1 at the time of writing.

What was decided to keep in the system from the previous version
1) Multisite
2) Multilanguage. Internationalization is done through Zend and Doctrine.
3) Modularity. At the same time, you can create a module in the system itself by specifying a yaml scheme and obtaining standard methods for working with controllers and auto-generated forms (Zend_Form).
4) In the created modules, by default there is support for i18n, versionable, timestampable.
Each site has display modes - backend, frontend, etc. The model is one for all. The basis for the models is Doctrine. It seemed very comfortable.

Accordingly, the application scheme turned out to be as follows: When you start the application, it is determined in what mode it starts, after which Boostrap starts. You can use the one located by default in / application. You can (as is done in the case of the installer) define your own. Launching the application The Xms_Application class performs initialization. The Bootstrap class is inherited from Xms_Core_Abstract, which in turn is inherited from Zend_Application_Bootstrap_Bootstrap. Run method:
/application
--->/backend
------>/helpers
------>/languages
------>/layouts
------>/modules
--->/frontend
--->/installer
/models
/tests
/library
--->/Xms
--->/Xms/Core
--->/Xms/Backend
--->/Xms/Frontend
--->/Zend
--->/Doctrine


$application = new Xms_Application(

                            APPLICATION_ENV,

                            array('config' => XMS_ROOT . '/config/application.ini',

                            'mode' => 'backend')

                            );

$application -> setBootstrap(APPLICATION_PATH . '/Bootstrap.php');

$application->bootstrap()->run();

require_once 'Zend/Loader/Autoloader.php';

require_once( 'Doctrine.php' );

Zend_Loader_Autoloader::getInstance()

                  ->pushAutoloader(array('Doctrine', 'autoload')); 

Zend_Loader_Autoloader::getInstance()->registerNamespace('Xms_');

Zend_Loader_Autoloader::getInstance()->registerNamespace('Scienta_');

     $this -> _readConfig();

     $this -> _setDb();

     $this -> _setEnvironment();

     $this -> _setLayout();

     $this -> _setSystem();

     $this -> _setSecurity();

 

     Zend_Registry::set( 'Xms_Bo', $this );

     parent::run();

A little more details about the methods _setEnvironment (), _setSystem () and _setSecurity ()
_setEnvironment () Here the application is initialized - loading of available modes, sites, modules, locales and routers. _setSystem () Here the modules are being installed. That is, a module that does not have a connection with the launched site will not be available. _setSecurity () From the point of view of differentiation of access rights, it was decided to dwell on the fact that the final resource will not be Zend_Action, but the controller itself. Well, just imagine the situation when a new action is added to the controller (which is more than likely with the same AJAX) and the procedure for changing roles and granting access rights to a new action :) Doctrine

protected function _setEnvironment()

{

Doctrine::loadModels(array(

        XMS_ROOT . DIRECTORY_SEPARATOR . 

            Xms_Application::APPLICATION_FOLDER . DIRECTORY_SEPARATOR . 

            Xms_Application::MODELS_FOLDER . DIRECTORY_SEPARATOR . 'core' . DIRECTORY_SEPARATOR .

            Xms_Application::MODELS_FOLDER_GENERATED,

        XMS_ROOT . DIRECTORY_SEPARATOR . 

            Xms_Application::APPLICATION_FOLDER . DIRECTORY_SEPARATOR . 

            Xms_Application::MODELS_FOLDER . DIRECTORY_SEPARATOR . 'core'

                                )

                            );

    $this->_defineUri();

    $this->_loadModes();

    $this->_loadSites();

    $this->_loadModules();

    $this->_loadLanguages();

    $this->_loadRouters();

}

foreach($this->_moduleMatrix as $key=>$val){

    $front->addControllerDirectory(XMS_ROOT . DIRECTORY_SEPARATOR .

        Xms_Application::APPLICATION_FOLDER . DIRECTORY_SEPARATOR .

        Xms_Application::APPLICATION_EXT . DIRECTORY_SEPARATOR .

        $this->_mode . DIRECTORY_SEPARATOR . Xms_Application::MODULES_FOLDER . DIRECTORY_SEPARATOR . $key, $key);

}

$this->_acl = new Xms_Core_Acl($this->_siteId, $this->_modeId);

$front->registerPlugin(new Xms_Core_Controller_Plugin_auth(Zend_Auth::getInstance(), $this->_acl));

This is why I especially thank the Doctrine developers for the Doctrine_Template.
Task: By default, tables are created with Doctrine_I18n, Versionable, SoftDelete, and Timestampable support. There was a problem - trac.doctrine-project.org/ticket/1708 . Inheritance and removal of unnecessary reference was able to quickly get away from this. In addition, now each entry is also characterized by belonging to the user and the site.

What we have at the moment.
1) Installer mode. System installation.
2) Backend mode. Adding a module causes tables, controllers, and forms to be created.
3) The frontend mode is in its infancy. It is thought to use Action_Stack to form pages in accordance with the modules connected to this page.

In addition to delimiting access rights to actions, the system needs to have delimiting rights to data. In addition to access to controller resources, the role will also have access to the data slice. A slice is formed on the basis of access to each field of the table.

I would like to use Zend_Project to generate new modes - I think about the opensocial mode (a social program with support for code.google.com/intl/en/apis/opensocial ), office (since schemes can be generated from yaml, then why not give a graphical tool for creating tables) , jquery-grid, etc.
Considering Doctrine_Event to make a process startup system. That is, an installation created by someone - when adding an entry to table A, causing the addition of an entry to table B and sending the email should work.

Here is an attempt to describe briefly what happened. Thanks to the habrayuzers for the notes with their experience - it means that it’s not only interesting for us to reinvent the wheel :)
The code is planned to be uploaded to OpenSource, so if anyone would be interested to see and feel it for the well.