CMS Development
The idea born in the process of developing your own CMS. It is often necessary that the same events be available simultaneously via the main html view, via ajax, or, for example, via a mobile phone. Naturally, it may be necessary not only to display data in different formats (html, JSON, xml), but also to perform additional actions depending on the environment.
You can do this with the help of conditions in a separate controller method, with separate methods for each type of display, or so ...
The idea is to separate the controller classes according to the display method.
Those. we create the main controller in which default methods for event handling are implemented.
')
Further, for each type of mapping, we create a controller, a successor to the main controller, and implement open methods for events that are available in this type. Or do stubs for methods that are not available.
We add the prefix (or postfix) to the name of the classes of these controllers according to the type. For example: IndexController_Web, IndexController_Ajax, IndexController_Mobile, etc.
Next, in the front controller, we determine in which environment the script works and which prefix should be used and call the controllers with the necessary prefix. If the required class does not exist, load the parent, so all methods will be available by default.
There is an option to implement in the parent controller only protected methods that implement actions common to all types or return data in a common format. Then in successors it is possible to describe only available methods, and unnecessary methods will not be available by default.
Advantages of this approach:
I have not yet found the minuses)
I think this approach can also be applied in existing CMS like Zend Framework, making small changes in the kernel or using plug-ins.
You can do this with the help of conditions in a separate controller method, with separate methods for each type of display, or so ...
The idea is to separate the controller classes according to the display method.
Those. we create the main controller in which default methods for event handling are implemented.
')
Further, for each type of mapping, we create a controller, a successor to the main controller, and implement open methods for events that are available in this type. Or do stubs for methods that are not available.
We add the prefix (or postfix) to the name of the classes of these controllers according to the type. For example: IndexController_Web, IndexController_Ajax, IndexController_Mobile, etc.
Next, in the front controller, we determine in which environment the script works and which prefix should be used and call the controllers with the necessary prefix. If the required class does not exist, load the parent, so all methods will be available by default.
There is an option to implement in the parent controller only protected methods that implement actions common to all types or return data in a common format. Then in successors it is possible to describe only available methods, and unnecessary methods will not be available by default.
Advantages of this approach:
- Type checking is performed only once at the front of the controller and there is no need to check the script operation conditions each time.
- The code is clearly divided and not littered
- Access to the same url in different environments
- The ability to easily close unnecessary methods.
I have not yet found the minuses)
I think this approach can also be applied in existing CMS like Zend Framework, making small changes in the kernel or using plug-ins.
Source: https://habr.com/ru/post/36606/
All Articles