Announcement and history of Explay CMS 3 (Core)

A bit of history

Somewhere in late August - early September, gradually understanding the paradigms of object-oriented programming and horrified by my old code, I decided to forget Explay 2.1 as a nightmare and took to writing everything from scratch. Yes, it was probably not the best step towards the users of the Explay, but you will excuse my stupid nature.

')

The main idea of ​​Explay 3 is to give the site developer complete control over the data types: add 10 fields to the article that are necessary on this project or even introduce a new data type, for example, gifts a la Vkontakte. With all this, the developer, introducing new types, should not waste time writing PHP code or their own modules. Mainly because of such universality, the system for several months of development has only the core and rather difficult one.



This time, the implementation of the plans to seize the world of thoughts did not begin with index.php, but from a blank sheet of paper. Having written several sheets up and down, I decided on the structure of the database. The very same ideology was clear in advance: the main entity is an object, and objects are classified by type. Thus, by the end of the first stage, 6 mandatory / main / source tables appeared in the database, describing everything and everyone, including themselves.

MySQL Workbench 5.0 OSS helped me a lot in designing the database.

The next step was the design and writing of interfaces for the “star” objects of the engine. From that moment began a long and unhurried work on the code, slowed down by the university and work.



Since December, I have become almost a free man and I started working closely with the engine - the development went faster. So now I present to you the core of the Explay CMS 3 engine. The efficiency is approximately 70-80%.

Someone may have seen my attempts to talk about the process of writing the engine, but, unfortunately, I was again not long enough :(

Specifications

Code

The code is completely on the OOP. OOP is used to the full extent with all the ensuing pros and cons. The CMS core is 24 classes: controllers and objects representing their records in the database - ORM (fields, types and simple objects). Without exception, the methods have already been commented on for further documentation.

Lyrical digression:



The three fundamental entities of the engine are three types of objects: an object of type, a field object, and an ordinary object.



Type is a category (type) of ordinary objects. In the physical sense, this is a table in which objects of a certain type are stored.

Field (Field) - a description of the properties of the object. In the physical sense - the field (column) of the table. But a field cannot always describe a column of a table of the type to which it belongs; fields can be related (“JOIN” properties of another type) and reference books (selectors whose values ​​are stored in a separate table).

An object is an entry in its type table.



To obtain an object, you need to know its type and id. All object properties are described by fields.

MVC

The pattern “Model-Representation-Controller”, to my happiness, turned out to be in the project not as a tribute to fashion, but as a need. Thanks to him, the tiny amount of code goes to the model / business logic / module. As a consequence, the beauty of the code and low development cost.

ModuleResponse is a required “response” object of the called module method. It contains data (objects) that will be represented as an XML table.

Fig. 1. Page Life Cycle

Templates

XSLT is used as a standard template engine. There is nothing special to say, beautiful :)



Implementation at the level of PHP code: the required template is set to the module response object (ModuleResonse) in a strange format: relative path to the xsl file without an extension (it is assumed that the template can be tpl). For example, in my :: __ default (): $response->setTemplate ('my/__default');



If the module method is called from the address bar, for example, example.com/module/method, then the template specified in its response will be used as the “point of entry”.



By the way, thanks to macros and modules that do not require any installation (with the exception of whether they are associated with any types), the latter can act as plugins connected from templates.



To simplify the life of the developer and coder, macros were introduced. Syntax: {{module_name :: method_name (parameters)}} . A template assembled according to the response of the specified module will simply be inserted in place of the macro. Maybe this is not the most beautiful version of the template assembly, but it is clearly faster than loading XML tables directly into XSLT through document ().

High loads and caching

Since CMS is focused on creating social networks and online communities, caching is all. The ideology of caching is the preservation of whole objects that, by the way, will never be obsolete, since when they change, the corresponding cache is reset.



The architecture of the engine does not allow you to select several objects with a single query to the database — for each object, its own query. Here sits the most important problem and the most delicious zest. For example, we have 100 comments on the article (100 requests + 1 cached per sample id list). When caching is turned off, we will always have 101 requests (obogi), and when enabled - at least 1. When a moderator changes a comment - at least 2, the same when adding a new object. Thus, having a fast cache engine we get a fairly flexible and relatively easy system. But I would recommend using CMS without caching only for home development.

~ / explay / classes / CacheController - front-end cache controller. Includes file and Memcache back end.



Perhaps a different lifetime for ordinary and system objects (approx. Author).

System requirements

Required:

• PHP 5.x
• Xslt
• MySQL with InnoDB support (preferably 5.1)
• mb_string
• mod_rewrite

Recommended:

• Memcahced

Launch

The current version in SVN is more likely to become familiar with the code and the architecture itself as a whole.



In the root folder is a file dump.sql - it is in the database. Settings in explay / config.php . Work module my .



The main rule of CNC: example.com/mod_module/method_methoda/param0/param1/.../paramN

example.com/something/uri/to/hell .xml - will give you an XML table of the module response :)

example.com/something/uri/to/hell ? debug - some Debug information.

The purpose of this article

This article is just an introductory description of the CMS. And Habrahabr is perhaps the only place where I can hear independent and professional reviews and I really need them. I would also like to know if anyone will work with her in the future. Criticism, advice, business suggestions are welcome.



View code in SVN



Thanks for attention!