Programmer's notes on the new features of MODx Revolution

In this article I want to consider some of the new features of MODx Revolution that were not in the younger branch - MODx Evolution. With this CMF, I started working when the version of modx-2.0.0-beta-2 was available, i.e. about a year and a half ago. I can say that from the summer of 2009, when the system was only in beta, until the release in the summer of 2010, MODx went a long way in its development, new features were added, the old functionality became faster and better. I believe that currently MODx Revolution is a really powerful platform for building a wide variety of web applications, from simple sites to large portals. So, let's begin.

I will try to describe the following innovations of MODx Revolution:
  1. xPDO
  2. Namespaces
  3. Contexts
  4. New caching system
  5. Internationalization

Now, first things first.


xPDO

First, an excerpt from the xPDO description from the official site :

xPDO is a lightweight ORB library that runs on PHP 4 and 5, providing the benefits of the new standard for database access in PHP 5.1 and higher - PDO. It implements a very simple but effective Active Record pattern for accessing data.

xPDO is an ORB library developed by the MODx community on which all system operation is based, even the main MODx class is an inheritor of the xPDO class. In MODx Revolution, all database operations are performed using xPDO, component developers are also recommended to use this library, however, the old mechanism for working with a database from MODx Evolution is left for backward compatibility.
xPDO allows you to use a single interface for communication with various types of databases. Connectors for MySQL and SQLite are currently available, in the future we plan to expand the list of supported databases.
All data manipulations are performed using specialized methods. For the selection, creation, updating and deletion of data, the use of direct queries is not required, which virtually eliminates SQL injection.

The following example selects from the database all resources in the web context for which the parent resource is set to 3 and prints their headers. In a similar way, the creation, editing and deletion of objects are performed:

//выбираем ресурсы по заданному условию
$resources = $modx->getCollection(“modResource”, array(
“parent” => 3,
“context_key” => “web”
));
//проходим по полученному массиву и выводим заголовок ресурса
foreach ($resources as $resource) {
echo($resource->get(“pagetitle”).”|”);
}




//создаем новый объект
$resource = $modx->newObject(“modResource”);
//устанавливаем заголовок и содержимое страницы
$resource->set(“pagetitle”, “Мой заголовок”);
$resource->set(“content”, “Мое содержимое”);
//и сохраняем в базу данных.
//Внимание! До вызова этого метода данные в базу данных не запишутся!
$resource->save();

//получаем ресурс с идентификатором 1
$resource = $modx->getObject(“modResource”, 1);
//устанавливаем новый заголовок
$resource->set(“pagetitle”, “Новый заголовок”);
//и сохраняем изменения
$resource->save();

//получаем ресурс с идентификатором 5
$resource = $modx->getObject(“modResource”, 5);
//и удаляем его
$resource->remove();


Namespaces

Namespaces are used to identify various components that are not part of the system core. In fact, the namespace is a folder in core / components that contains model files for xPDO, dictionaries, and other resources necessary for components.
Namespaces are also used to create additional pages and menu items in the administration system.
Each external component must have its own namespace, which can be created in the administration system.

Contexts

Context is the storage of resources in MODx. Each resource must relate to one of the contexts. The context has a separate cache of the resource tree belonging to it. Accordingly, every time you add or remove a resource from the context, the system clears the cache. When the context is accessed again, the resource tree is generated and written to the cache, which can cause some slowdowns in the site’s work when resources are often added or removed. Therefore, in the presence of a frequently updated site with a large number of documents, it may be reasonable to place certain sections in separate contexts.

Context access policies are implemented using a set of rights that are set for a specific group of users in a certain context. Therefore, you can prevent certain users from editing or even viewing resources in a specific context.
By default, after installation, there are 2 contexts in the system: web (context of the user part of the site) and mgr (context of the administrative panel).

In the context of the web, anonymous users have rights only to view resources, and users who are members of the Administrator group have full rights to all actions with resources. Accordingly, in the context of mgr, only users from the Administrator group can perform any actions with resources.
Contexts can be used to create several sites on a single MODx Revolution installation, as well as to create subdomains in which site users can post their materials. However, to implement this behavior, a small edit to the index.php file will be required, since the web context is initialized in it by default, and we will need to initialize other contexts in some cases.

New caching system

MODx Revolution provides a new caching system, with which the programmer can store any data in the cache and completely control their life cycle. Example of writing and retrieving data from the cache (taken from the official MODx documentation ): You can also delete saved data. Uninstall example:

// пишем что-то в кэш
$colors = array('red','blue','green');
$modx->cacheManager->set('colors',$colors); /* запишется в core/cache/colors.cache.php */

// теперь получаем записанные данные
$colors = $modx->cacheManager->get('colors');
foreach ($colors as $color) {
echo $color.'-';
} /* выведет 'red-blue-green' */





$modx->cacheManager->delete('colors');


Internationalization

MODx Revolution allows you to create internationalized versions of sites using dictionaries that are stored in files or a database. Dictionaries are divided into the following levels: languages, topics, and lines. In the file system, languages ​​are folders that contain files with themes, which, in turn, contain strings.

Consider the example of organizing the storage of MODx system dictionaries in the file system.
The root folder of dictionaries contains subfolders whose names match the language designations accepted by IANA (for example, en or ru). Further, each language subfolder contains files with names in the format theme_name.inc.php. And each file with a theme contains a line in the format

$_lang['идентификатор_строки'] = 'значение_строки';

On the site page, the value of the line from the dictionary is inserted with the following tag:

[[%идентификатор_строки? &topic=`имя_темы` &namespace=`modx` &language=`язык`]]

The namespace parameter is used to specify the namespace for which the lexicon should be loaded. The language parameter is optional, if it is absent, the language set in the system default settings will be selected.

I tried to consider only some of the new features of MODx Revolution. This system is fraught with much more than I can now imagine. I am pleased to continue to study this wonderful, in my opinion, CMF, and have never once been disappointed in it.

Resources

  1. Official MODx website
  2. MODx Documentation
  3. XPDO website
  4. MODx Russia
  5. Unofficial Russian-speaking community MODx

Also popular now: