What do we know about MODX 3 at the moment?
a Few weeks ago lead architect Jason coward (Jason Coward, "opengeek") shared his vision about the future of MODX at the site Medium. Based on this information, as well as other discussions that we know about MODX 3? What is its status and when we can see something live?
Frankly, we don't yet have precise answers. There are just some pieces of information that we can put together. Because MODX 3 has simply not established, there are many assumptions and "progressive" assumptions. MODX 3 is a long – term project that just started.
the
A lot of people are fine using the current version of MODX. The system allows designers and frontend developers to create completely unique sites with minimal effort and modifications to the core unlike some of its competitors. Even in the current version of the development sites will be simple and completely feasible thing for many years. Very powerful language patterns and items additional fields (TV) and expansion – everything is ready for future use.
Perhaps the greatest reason why we need MODX 3, is just a number. To cleanse legacy code and providing developers with improved tools, relevant industry standards, the system, MODX will need breaking changes. And since MODX follows the principles of semantic versioning, this means that the major version should be increased at the time of implementation of critical changes. For MODX Revolution installed version # 2, so we will need a version # 3.
So why do we need a breaking change, if the current version MODX is still very relevant? I would say it is necessary to MODX have followed the thread changes the world of PHP. The PHP community is getting more professional and standardized (in particular, thanks The Framework Interoperability Group group of the concept of compatibility and initiatives like PHP: The Right Way – PHP: the right way) with impressive speed in the last few years. Joining in this movement, the core code of MODX can be much more classy (read: stable, testing and possibly smaller). Conversely, MODX would be a much more attractive platform for other developers in PHP.
In world development, critical changes occur constantly. With exceptional jump from Evo to MODX Revo was actually more stable and continued to develop in past years, but from certain points of view critical release that needs to happen to surpass everything that allows the existing code.
the
In many cases, MODX was developed with the use of the concept of "rejection of an alien development" (a tendency to consciously or instinctively ignore all the innovations that occur outside the organization – approx. translator), which is not the best pattern design. Basically this means that if previously each part of the code was developed within the community of MODX, in the future can be used more standardized libraries that are developed by external communities. Thanks Composer and Packagist, such a change occurred inside the PHP community in recent years, enabling the most simple to use code from external developers, and accelerated the growth of separate libraries that perform exceptionally well one, clearly defined task.
Connecting such external third-party libraries, it becomes possible to develop reliable applications faster and better using the advantages of fully tested code of the individual modules (unit tests). Because now, in MODX there are no useful unit tests (although still there is some movement), it is of great importance from the point of view of architecture and code quality.
I will cite some examples of modules that have been developed within the team MODX earlier to use external libraries:
the
It's only the first things that come to mind when we talk about re-using ready-made code.
the
In the second part of his series of articles, "Maintaining MODX-to-date", Jason said framework Slim (version 3) as the most likely candidate for use in the core of MODX. This has not gone unnoticed – many people begin to look Slim, figuring out what it is and how it works.
the Here's what we need to know about Slim:
the
Presumably, the Slim will take the place of the current handlers of requests and responses in MODX. Given the ability to add middleware code, this would lead to an extremely flexible and powerful system.
the
If you ask a random group of MODX developers about their most hated part of the system, most likely it will be ExtJS (or in more General terms – "Manager"). At the moment there is no specific direction for the Manager, which I knew, but the reference to the ExtJS 3.4 is clearly not what should happen. ExtJS 3 is very outdated, it is not fast enough and does not adequately support mobile devices. Moreover, ExtJS 3.4 is no longer being updated, since ExtJS is already available 6 early access.
So although we don't yet know how it will look like the Manager or what it is built, we can be quite sure that it will not ExtJS 3.
the But what do we know?
Given the choice of Jason as a Slim core library, his work on a project Tacit ("high-performance RESTful framework," based on the Slim), and also some discussion in various IRC channels Slack, the most it seems that the next Manager will get a RESTful API as its basis. The current Manager also has an API, but its structure is not completely standardized, and sometimes aimed at what ExtJS expects. It's definitely not RESTful.
During the transition to RESTful APIs as the core services backend and interface will be further divided from the point of view of the code. This should allow easier to develop a truly unique Managers, and to do these two parts of the platform independently of each other. Designers could focus on the development of the interface Manager is the third version, and developers, meanwhile, would work on a reliable API.
the
Right now Jason is working on the long-awaited third part of his series of articles about the future of MODX. In this part, he will share his vision on the theme of sustainability – basically, interaction with the database. For architecture MODX is a very important decision, so Jason prepares a few options before publishing the results.
At the moment the main focus of MODX is version 2.3 and the upcoming 2.4 version. The release of MODX 3 promises to be exciting and attractive, so it is important to spend some time to develop solutions before defining the foundations of a new revolution in MODX.
Article based on information from habrahabr.ru
Frankly, we don't yet have precise answers. There are just some pieces of information that we can put together. Because MODX 3 has simply not established, there are many assumptions and "progressive" assumptions. MODX 3 is a long – term project that just started.
the
Why we still need ALL 3?
A lot of people are fine using the current version of MODX. The system allows designers and frontend developers to create completely unique sites with minimal effort and modifications to the core unlike some of its competitors. Even in the current version of the development sites will be simple and completely feasible thing for many years. Very powerful language patterns and items additional fields (TV) and expansion – everything is ready for future use.
Perhaps the greatest reason why we need MODX 3, is just a number. To cleanse legacy code and providing developers with improved tools, relevant industry standards, the system, MODX will need breaking changes. And since MODX follows the principles of semantic versioning, this means that the major version should be increased at the time of implementation of critical changes. For MODX Revolution installed version # 2, so we will need a version # 3.
So why do we need a breaking change, if the current version MODX is still very relevant? I would say it is necessary to MODX have followed the thread changes the world of PHP. The PHP community is getting more professional and standardized (in particular, thanks The Framework Interoperability Group group of the concept of compatibility and initiatives like PHP: The Right Way – PHP: the right way) with impressive speed in the last few years. Joining in this movement, the core code of MODX can be much more classy (read: stable, testing and possibly smaller). Conversely, MODX would be a much more attractive platform for other developers in PHP.
In world development, critical changes occur constantly. With exceptional jump from Evo to MODX Revo was actually more stable and continued to develop in past years, but from certain points of view critical release that needs to happen to surpass everything that allows the existing code.
the
the Syndrome "is not invented by us"
In many cases, MODX was developed with the use of the concept of "rejection of an alien development" (a tendency to consciously or instinctively ignore all the innovations that occur outside the organization – approx. translator), which is not the best pattern design. Basically this means that if previously each part of the code was developed within the community of MODX, in the future can be used more standardized libraries that are developed by external communities. Thanks Composer and Packagist, such a change occurred inside the PHP community in recent years, enabling the most simple to use code from external developers, and accelerated the growth of separate libraries that perform exceptionally well one, clearly defined task.
Connecting such external third-party libraries, it becomes possible to develop reliable applications faster and better using the advantages of fully tested code of the individual modules (unit tests). Because now, in MODX there are no useful unit tests (although still there is some movement), it is of great importance from the point of view of architecture and code quality.
I will cite some examples of modules that have been developed within the team MODX earlier to use external libraries:
the
-
the
- Logging. At the moment there is a convenient method $modx- > log(), however, if you change the method in accordance with the interface support PSR-3 developers will be able to reset the log record into various systems of logging, for example, such as Monolog. System Monolog provides a huge number of impressive features management logs, and when MODX will support PSR-3, it will be possible to support all of them without changing the core of MODX. the
- Routing. There are libraries that can do pretty cool stuff with the transform query in the correct answer. See the section below on Slim framework. the
- template System. Honestly, I really like the template language in Revolution, but maybe use something more "standard" like the Twig could be an interesting improvement. In any case, it will reduce the learning curve for many people since Twig is used in many other projects.
It's only the first things that come to mind when we talk about re-using ready-made code.
the
What is Slim and why use it?
In the second part of his series of articles, "Maintaining MODX-to-date", Jason said framework Slim (version 3) as the most likely candidate for use in the core of MODX. This has not gone unnoticed – many people begin to look Slim, figuring out what it is and how it works.
the Here's what we need to know about Slim:
the
-
the
- Slim – is router. He transformerait Queries (e.g. GET /manager/resource/update) in Response (e.g. a form to update a resource). the
- Slim support pattern Middleware (middleware). When using this pattern, you essentially get a lot of layers that handle each individual request, and answers with the ability to change them before they reach the next layer. Technical explanation of the pattern of the Middleware can find here. The Middleware pattern is a very effective way to extend behavior. Slim 3 in fact supports the standard PSR-7 (draft) of PHP-FIG in its implementation of the Middleware, which means that any middleware code with the support of the pattern PSR-7 can be safely used along with Slim 3. the
- Slim 3 is still in development; in other words, he's not ready for real production, but it looks like the code Slim 3 becomes stable.
Presumably, the Slim will take the place of the current handlers of requests and responses in MODX. Given the ability to add middleware code, this would lead to an extremely flexible and powerful system.
the
What about the Manager and ExtJS?
If you ask a random group of MODX developers about their most hated part of the system, most likely it will be ExtJS (or in more General terms – "Manager"). At the moment there is no specific direction for the Manager, which I knew, but the reference to the ExtJS 3.4 is clearly not what should happen. ExtJS 3 is very outdated, it is not fast enough and does not adequately support mobile devices. Moreover, ExtJS 3.4 is no longer being updated, since ExtJS is already available 6 early access.
So although we don't yet know how it will look like the Manager or what it is built, we can be quite sure that it will not ExtJS 3.
the But what do we know?
Given the choice of Jason as a Slim core library, his work on a project Tacit ("high-performance RESTful framework," based on the Slim), and also some discussion in various IRC channels Slack, the most it seems that the next Manager will get a RESTful API as its basis. The current Manager also has an API, but its structure is not completely standardized, and sometimes aimed at what ExtJS expects. It's definitely not RESTful.
During the transition to RESTful APIs as the core services backend and interface will be further divided from the point of view of the code. This should allow easier to develop a truly unique Managers, and to do these two parts of the platform independently of each other. Designers could focus on the development of the interface Manager is the third version, and developers, meanwhile, would work on a reliable API.
the
What next?
Right now Jason is working on the long-awaited third part of his series of articles about the future of MODX. In this part, he will share his vision on the theme of sustainability – basically, interaction with the database. For architecture MODX is a very important decision, so Jason prepares a few options before publishing the results.
At the moment the main focus of MODX is version 2.3 and the upcoming 2.4 version. The release of MODX 3 promises to be exciting and attractive, so it is important to spend some time to develop solutions before defining the foundations of a new revolution in MODX.
Comments
Post a Comment