November 25, 2009

Plugin code and naming convention proposal

Tags: , , , ,
Filed under: ZenMagick — DerManoMann @ 10:37 pm

A few days ago I wrote about the ‘ZM’ prefix and plugins. The prefix is useful but, as Raine pointed out it would be good to have something to avoid naming conflicts.

Seeing that it will be a while before we can start using PHP’s new namespaces a different solution must be found.

Since the ‘ZM’ prefix should be allowed I guess the only (and perhaps best) solution is to use ‘ZM’ in conjunction with something else. Since we are talking about plugins, this could be either the word ‘Plugin’, or the plugins name.

To be really useful the plugin name seems to be a good solution. I guess I’ll have to refactor all plugins anyway, so the work comes out the same (it might take a bit longer, though).

So, here’s what things could/should be in the future:

1. Plugin Name

As before, a plugin can either be a single .php file or a subfolder containing all the plugin files. The main plugin file (either as single file or in the plugin folder) is expected to start with ‘ZMPlugin’, followed by the plugin name.

The plugin folder name  needs to be the same as the plugin name (with underscores ‘_’ to indicate word borders).

Example1:

Plugin name: ‘minify’

Folder name: ‘minify’

Main plugin file: ‘ZMPluginMinify.php’

Other plugin classes: ‘ZMMinifyHelperClass1.php’, etc.

Other plugin static code: ‘minify_functions.php’, etc.

Example2:

Plugin name: ‘master_password’

Folder name: ‘master_password’

Main plugin file: ‘ZMPluginMasterPassword.php’

Other plugin classes: ‘ZMMasterPasswordHelperClass1.php’, etc.

Other plugin static code: ‘master_password_functions.php’, etc.

The convetions for other classes and other static code are actually just that: conventions. There won’t be any code to enforce this naming pattern.
The class name of the main plugin class/file will be requires (as it is now, just with different rules).

How’s that sound?

EDIT: I just tried this and all that is required is a change to ZMPlugins::getPluginForId(...). If I implement this I’ll also remove the zm_ prefix from the plugin folders, so in places where the plugin is looked up by name [for example: ZMPlugins::instance()->getPluginForId('zm_wordpress')] the name/id needs to change…

4 Comments

  1. Regarding file naming, I think we should stick to unix convention and also avoid using uppercase in file name if possible.

    Also, instead of loading everything automatically, should we also consider the option to load on demand?

    For example, my ssu plugins will look like this
    plugins/ssu/core.php
    plugins/ssu/parsers/
    plugins/ssu/whatever/
    ….

    ZM should auto load only the core.php file, this core file will decides to load whatever file the plugin needs. That way I can decide to load only the things I need when I do need it and also the implementation of the plugin system will be so much easier. What do you think?

    Comment by Raine — December 2, 2009 @ 5:50 am

  2. Oops, submit too soon

    Also, perhaps getPluginById makes more sense in English?

    Comment by Raine — December 2, 2009 @ 5:52 am

  3. Well, yes and no. I think I’d rather stick with uppercase to properly reflect the class name, but then I would consider this a minor things. So far I’ve never heard of any problems with that.
    ZenMagick doesn’t load everything. The only files that are included are *static* ones (funny enough, the convention here is a filename with only lower case…). Since the loader assumes functions, defines, whatever in there it needs to be loaded as that can’t be resolved at runtime.
    All other files are scanned and only loaded on demand (that is all in ZMLoader).
    Plugins also have the option to control this behaviour to a degree [there is a method setLoaderPolicy(..) for that]

    Comment by DerManoMann — December 2, 2009 @ 10:31 am

  4. … as opposed to? Sorry, I think I don’t get the question here?

    Comment by DerManoMann — December 2, 2009 @ 10:32 am

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.