CMS Development

    An idea born in the process of developing your own CMS. Often it is necessary that the same events be available simultaneously through the main html view, through ajax, or, for example, through a mobile phone. Naturally, it may be necessary not only to output data in different formats (html, JSON, xml), but also to perform additional actions depending on the environment.

    You can implement this using the conditions in a separate controller method, you can use separate methods for each type of display, or you can ...

    The idea is to separate controller classes by display method.

    Those. we create the main controller in which default methods for event processing are implemented.

    Further, for each type of display, we create a controller, the successor of the main controller, and implement open methods for events that are available in this type. Or do stubs for methods that are not available.

    Add the prefix (or postfix) to the class names of these controllers according to the type. For example: IndexController_Web, IndexController_Ajax, IndexController_Mobile, etc.

    Further, in the front controller, we determine in which environment the script works and which prefix should be used and call the controllers with the desired prefix. If the desired class does not exist, load the parent, so that all methods by default will be available.

    There is an option to implement only protected methods in the parent controller that implement actions that are common to all types or that return data in a common format. Then only the available methods can be described in the heirs, and unnecessary methods will not be available by default.

    The advantages of this approach:
    • Type checking is carried out only once in the front controller and there is no need to check the script working conditions every time
    • The code is clearly separated and not cluttered
    • Access on the same url in different environments
    • Ability to easily close unnecessary methods

    I haven’t found any cons yet)

    I think this approach can be applied to existing CMS like Zend Framework by making small changes in the kernel or using plugins.

    Also popular now: