1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

[Docs] Object-Oriented versus Procedural Plugins

Discussion in 'Archived Docs' started by Nick, Sep 28, 2009.

  1. Nick

    Nick Well-Known Member

    Update: As of Hotaru 0.7, all plugins must be object-oriented.

    This post is to outline the main differences between object-oriented and procedural plugins in Hotaru CMS.

    Overview

    Hotaru Plugin developers are encouraged to make object-oriented plugins for the following reasons:

    - your plugin code can be easily reused and extended
    - you can use default methods in parent classes
    - your code will look cleaner
    - the documentation in these forums is intended for object-oriented plugins

    Procedural example

    Prior to Hotaru 0.6, all plugins were procedural, kind of like Wordpress plugins. A plugin would consist of a number of functions and to prevent function names clashing we added a unique prefix to every function name. Procedural plugins used the $plugins global variable to access methods in the PluginFunctions and Plugin classes, but had to specify their own names within each function.

    Here's a very basic example of a procedural plugin. All this plugin does is include its own language file:

    PHP:
    <?php
    /**
     * name: Procedural Plugin
     * description: Example of a procedural plugin
     * version: 0.1
     * folder: procedural_plugin
     * prefix: pp
     * hooks: hotaru_header
     */

    function pp_hotaru_header()
    {
        global 
    $plugins;

       
    $plugins->includeLanguage('procedural_plugin''procedural_plugin');
    }

    ?>
    Object-oriented example

    Here's the same plugin as an object-oriented plugin. Note the following differences:

    1. Instead of a "prefix" in the comment block, we have a class name.
    2. The functions are wrapped in a class which extends PluginFunctions.
    3. The function is public so other classes can use it
    4. There's no prefix on the function name
    5. There's no need for the $plugins global because this plugin is a child class of PluginFunctions which itself inherits from Plugin.
    6. There's no need to give the includeLanguage method a filename and plugin name. It already knows the plugin name and assumes the filename is the same, unless specified otherwise. Most functions in PluginFunctions behave the same way.

    PHP:
    <?php
    /**
     * name: Object-Oriented Plugin
     * description: Example of an oo plugin
     * version: 0.1
     * folder: oo_plugin
     * class: ObjectOrientedPlugin
     * hooks: hotaru_header
     */

    class ObjectOrientedPlugin extends PluginFunctions
    {
        public function 
    hotaru_header()
        {
            
    $this->includeLanguage();
         }
    }

    ?>
    A little bit of magic

    In object-oriented programming, you extend a class in order to use, change or add additional functionality to the class you're extending. In this case, our ObjectOrientedPlugin class extends PluginFunctions which extends Plugin. That means that if a function already exists in one of those classes, you don't have to repeat it in your plugin unless you want to override it.

    The Plugin.php class in the /libs folder has a number of default functions for plugin hooks. These perform common tasks such as including files. For example, the above hotaru_header function is one of the default functions, and its sole purpose is to include a language file. That means we can completely eliminate that function from our plugin, just as long as the hook is still in the hooks list.

    Here's the final plugin:

    PHP:
    <?php
    /**
     * name: Object-Oriented Plugin
     * description: Example of a oo plugin
     * version: 0.1
     * folder: oo_plugin
     * class: ObjectOrientedPlugin
     * hooks: hotaru_header
     */

    class ObjectOrientedPlugin extends PluginFunctions
    {

    }

    ?>
    That empty class will do the same as the two previous code examples! With that in mind, it's worth looking through /libs/Plugin.php to see what default functions there are and what they do. It might save you a some time and code if you can just fall back on those defaults.
     

Share This Page