What do we know about MODX 3 at the moment?
A few weeks ago, lead architect Jason Coward ("opengeek") shared his vision of the future of MODX at the Medium site. Based on this information, as well as other online discussions, what do we know about MODX 3? What is its status, and when can we see something live?
Honestly, we have no exact answers yet. There are only some pieces of information that we can put together. Since MODX 3 has not yet been created, there are many assumptions and "advanced" assumptions. MODX 3 is a long-term project that is just starting up.
Many people make great use of the current version of MODX. The system allows designers and front-end developers to create completely unique sites with minimal effort and kernel changes, unlike some competitors. Even in the current version, website development will be simple and completely feasible for many years to come. A very powerful language of templates and elements, additional fields (TV) and extensions - all this is already ready for future use.
Perhaps the biggest reason why we need MODX 3 is just a number. In order to clean up the legacy code and provide developers with improved tools that meet industry standards, the MODX system will need critical changes. And since MODX follows the principles of semantic versioning , this means that the major version should increase at the time of the implementation of critical changes. Version 2 has been installed for MODX Revolution, which means we will need version 3.
')
So why do we need critical changes if the current version of MODX is still very relevant? I would say it is necessary for MODX to follow the flow of changes in the PHP world. The PHP community is becoming more professional and standardized (in particular, thanks to The Framework Interoperability Group - a group of compatibility concepts and initiatives like PHP: The Right Way - PHP: the right way) with an impressive speed in the last few years. By engaging in this movement, the MODX kernel code can become much more cool (read: stable, testable, and possibly smaller in volume). Conversely, MODX would be a much more attractive platform for other PHP developers.
In the development world, critical changes occur constantly. With an exceptional leap from Evo to Revo, MODX has actually become more stable and has continued to evolve over the past years, but from certain points of view, a critical release has to occur in order to surpass everything that the existing code allows.
In many cases, MODX was developed using the concept of “not accepting someone else's development” (the tendency to consciously or instinctively ignore all innovations that occur outside the organization - note of the translator) , which is not the best design pattern. Basically, this means that if previously each part of the code was developed within the MODX community, then in the future more standardized libraries that are developed by external communities can be used. Thanks to Composer and Packagist , such a change has occurred within the PHP community in recent years, which has made it as easy as possible to use code from external developers, and has also accelerated the growth of individual libraries that perform an exceptionally well one, clearly defined task.
By connecting such external third-party libraries, it becomes possible to develop reliable applications faster and better, taking advantage of the fully tested code of individual modules (unit tests). Since now there are no useful unit tests in MODX (although there is still some movement ), this is of great importance in terms of architecture and code quality.
I will give some examples of modules that were developed within the MODX command earlier before using external libraries:
These are only the very first things that come to mind when we talk about reusing ready-made external code.
In the second part of his series “ Maintaining MODX up to date, ” Jason noted Slim framework (version 3) as the most likely candidate for use in the MODX core. This did not go unnoticed - many people began to consider Slim, figuring out what it is and how it works.
Here is what we need to know about Slim:
Slim is supposed to take the place of the current request and response handlers in MODX. Given the possibility of adding middleware-code, this would lead to an extremely flexible and powerful system.
If you ask a random group of MODX developers about their least favorite part of the system, most likely it will be ExtJS (or more generally, the “Manager”). At the moment there is no definite direction for the Manager, which I would know about, but binding to ExtJS 3.4 is clearly not what should happen. ExtJS 3 is very outdated, it is not fast enough and does not provide adequate support for mobile devices. Moreover, ExtJS 3.4 is no longer being updated, since ExtJS 6 is already available in early access .
So although we do not yet know how the Manager will look or what it will be built on, we can be quite sure that this will not be ExtJS 3.
But what do we know?
Considering Jason’s choice of Slim as the core library, his work on a Tacit project (a “high-performance RESTful framework” based on Slim), as well as some discussions in various IRC channels and Slack , it’s most likely that the next Manager will receive a RESTful API as its basis. The current Manager also has an API, but its structure is not fully standardized, and in some places it is aimed precisely at what ExtJS expects from it. This is definitely not RESTful.
When switching to the RESTful API as the main service, the backend and interface will be further separated in terms of code. This should make it easier to develop truly unique Managers, and to do these two parts of the platform independently. Designers could focus on developing a third-version Manager interface, while developers would be working on a robust API in the meantime.
Right now, Jason is working on the long-awaited third part of his series on the future of MODX. In this part, he will share his vision on sustainability - mainly interactions with the database. For MODX, this is a very important decision, so Jason prepares several possible options before publishing the results.
At the moment, the main focus of MODX is version 2.3 and the upcoming version 2.4. The release of MODX 3 promises to be exciting and attractive, so it is important to spend some time to come up with solutions before defining the foundations of a new revolution in MODX.
Honestly, we have no exact answers yet. There are only some pieces of information that we can put together. Since MODX 3 has not yet been created, there are many assumptions and "advanced" assumptions. MODX 3 is a long-term project that is just starting up.
Why do we still need MODX 3?
Many people make great use of the current version of MODX. The system allows designers and front-end developers to create completely unique sites with minimal effort and kernel changes, unlike some competitors. Even in the current version, website development will be simple and completely feasible for many years to come. A very powerful language of templates and elements, additional fields (TV) and extensions - all this is already ready for future use.
Perhaps the biggest reason why we need MODX 3 is just a number. In order to clean up the legacy code and provide developers with improved tools that meet industry standards, the MODX system will need critical changes. And since MODX follows the principles of semantic versioning , this means that the major version should increase at the time of the implementation of critical changes. Version 2 has been installed for MODX Revolution, which means we will need version 3.
')
So why do we need critical changes if the current version of MODX is still very relevant? I would say it is necessary for MODX to follow the flow of changes in the PHP world. The PHP community is becoming more professional and standardized (in particular, thanks to The Framework Interoperability Group - a group of compatibility concepts and initiatives like PHP: The Right Way - PHP: the right way) with an impressive speed in the last few years. By engaging in this movement, the MODX kernel code can become much more cool (read: stable, testable, and possibly smaller in volume). Conversely, MODX would be a much more attractive platform for other PHP developers.
In the development world, critical changes occur constantly. With an exceptional leap from Evo to Revo, MODX has actually become more stable and has continued to evolve over the past years, but from certain points of view, a critical release has to occur in order to surpass everything that the existing code allows.
Syndrome "it is not we invented"
In many cases, MODX was developed using the concept of “not accepting someone else's development” (the tendency to consciously or instinctively ignore all innovations that occur outside the organization - note of the translator) , which is not the best design pattern. Basically, this means that if previously each part of the code was developed within the MODX community, then in the future more standardized libraries that are developed by external communities can be used. Thanks to Composer and Packagist , such a change has occurred within the PHP community in recent years, which has made it as easy as possible to use code from external developers, and has also accelerated the growth of individual libraries that perform an exceptionally well one, clearly defined task.
By connecting such external third-party libraries, it becomes possible to develop reliable applications faster and better, taking advantage of the fully tested code of individual modules (unit tests). Since now there are no useful unit tests in MODX (although there is still some movement ), this is of great importance in terms of architecture and code quality.
I will give some examples of modules that were developed within the MODX command earlier before using external libraries:
- Journaling At the moment there is a convenient $ modx-> log () method, but when this method changes in accordance with the PSR-3 interface support, developers will be able to reset the log entries to various logging systems, such as Monolog , for example . Monolog provides a huge amount of impressive log management capabilities, and when MODX starts to support PSR-3, you can support any of them without modifying the MODX kernel.
- Routing There are libraries that can do pretty cool things to transform the query into the correct answer. See the Slim Framework section below.
- Template system. Honestly, I really like the template language in Revolution, but perhaps using something more “standard” like Twig could be an interesting improvement. In any case, this will reduce the learning curve for many people, since Twig is used in many other projects.
These are only the very first things that come to mind when we talk about reusing ready-made external code.
What is Slim and why use it?
In the second part of his series “ Maintaining MODX up to date, ” Jason noted Slim framework (version 3) as the most likely candidate for use in the MODX core. This did not go unnoticed - many people began to consider Slim, figuring out what it is and how it works.
Here is what we need to know about Slim:
- Slim is a router. It transforms Requests (for example, GET / manager / resource / update) into an Answer (for example, into a form for updating the resource).
- Slim supports the Middleware pattern (middleware). When using this pattern, you essentially get a lot of layers that process each individual request, as well as answers with the ability to change them before they reach the next layer. A technical explanation of the Middleware pattern can be found here . The Middleware pattern is a very effective way to expand behavior. Slim 3 actually supports the PSR-7 standard (draft) from PHP FIG in its Middleware implementation, which means that any middleware code supporting the PSR-7 pattern can be safely used along with Slim 3.
- Slim 3 is still under development; in other words, it is not yet ready to work in real production, but it seems that the Slim 3 code is becoming stable.
Slim is supposed to take the place of the current request and response handlers in MODX. Given the possibility of adding middleware-code, this would lead to an extremely flexible and powerful system.
What about Manager and ExtJS?
If you ask a random group of MODX developers about their least favorite part of the system, most likely it will be ExtJS (or more generally, the “Manager”). At the moment there is no definite direction for the Manager, which I would know about, but binding to ExtJS 3.4 is clearly not what should happen. ExtJS 3 is very outdated, it is not fast enough and does not provide adequate support for mobile devices. Moreover, ExtJS 3.4 is no longer being updated, since ExtJS 6 is already available in early access .
So although we do not yet know how the Manager will look or what it will be built on, we can be quite sure that this will not be ExtJS 3.
But what do we know?
Considering Jason’s choice of Slim as the core library, his work on a Tacit project (a “high-performance RESTful framework” based on Slim), as well as some discussions in various IRC channels and Slack , it’s most likely that the next Manager will receive a RESTful API as its basis. The current Manager also has an API, but its structure is not fully standardized, and in some places it is aimed precisely at what ExtJS expects from it. This is definitely not RESTful.
When switching to the RESTful API as the main service, the backend and interface will be further separated in terms of code. This should make it easier to develop truly unique Managers, and to do these two parts of the platform independently. Designers could focus on developing a third-version Manager interface, while developers would be working on a robust API in the meantime.
What's next?
Right now, Jason is working on the long-awaited third part of his series on the future of MODX. In this part, he will share his vision on sustainability - mainly interactions with the database. For MODX, this is a very important decision, so Jason prepares several possible options before publishing the results.
At the moment, the main focus of MODX is version 2.3 and the upcoming version 2.4. The release of MODX 3 promises to be exciting and attractive, so it is important to spend some time to come up with solutions before defining the foundations of a new revolution in MODX.
Source: https://habr.com/ru/post/259197/
All Articles