CMS has a standard structure: website and admin panel. In the admin using the TinyMCE editor, the user (content manager) creates pages. Some pages should have different html-objects: (order form and send feedback, photo gallery and others). Naturally, such objects (plug-ins) should be created separately from the editor and then integrated into the page.

At the moment I have this implementation of the plug-in:

When creating, for example, a service order page , the user writes in the editor:

Дорогой вы наш пользователь! На этой странице вы можете сделать заказ услуги. {{order_service}}

This text is stored in the database. When accessing the page, the Model responsible for displaying the pages of the site parses regularly the data from the database and, if there is a file of the same name, order_service.php enables it (require "order_service.php"). The code of this file generates the html order form of the service and inserts it instead of {{order_service}}. The resulting html-page with the form is displayed in the browser.

The order_service.php file also contains the processing code for the incoming post-data, makes queries to the database (singleton class), checks the data and places them in the database.

The question is, in fact, is such a technology correctly implemented in terms of MVC? After all, the processing of the form and access to the database is not done using the methods of the corresponding model, but directly in the code of the plugin itself. Are there more flexible options for implementing this kind of plug-ins?

    1 answer 1

    At first, short and to the point

    The model delegates part of the processing to the plugin, like nothing criminal. Everything is as it should, if the plugin itself is also implemented via MVC.

    Now a lengthy comment

    Any successful programs, as a rule, change. It is not always possible to anticipate what changes these will be, but you can prepare for them. If you maintain good modularity, future changes will cost less effort. The meaning of sensible design (using MVC, and any other patterns) is to divide the code responsible for different tasks into modules in order to facilitate development and maintenance.

    Each class (or source file) should have only one reason for changing it: the color scheme of the site has changed - we reigned, the structure of the tables in the database was updated - we reformed the model ... Otherwise, to replace one plug-in with another, half of the source code would have to be cracked. And that would mean that something was wrong with the system. If each source file at you solves some kind of its own task, without interfering with others, then we can say that the modularity of the system is good or at least satisfactory.

    PS In general, in my opinion, there are no right and wrong decisions - there are solutions that will give a certain result in a specific task. And if in your project the described solution has allowed for achieving sufficient flexibility (and will not cause a headache in the future), it can be called successful.

    • Then the question is solved! After all, each of the plug-ins includes its own view files and models, as well as a separate css file. - Deus