thoughts on the ZM class prefix
The naming conventions currently state that only core classes should use the ‘ZM’ prefix for class names.
I think that this is not correct. The prefix is part of the unique loader concept in ZenMagick and prohibiting the use of the prefix outside core would take away some of that for advantage.
The prefix is there for two main reasons:
- It helps avoiding name conflicts with zen cart code.
- The prefix allows the loader to resolve the actual used implementation at runtime.
Taking away the second from plugins would actually mean that it would not be possible to further customize plugins without changing plugin files.
Perhaps the rule should be changed to something like:
‘The first class to implement some feature should use the ZM prefix.’
That way, all code further down the road can easily extend/replace the class using regular loader features.
I think the problem with using ZM for non core classes is to avoid conflicts. If an author write a plugin, perhaps he can name it ZMPluginWhatever (ZMPlugin as a prefix) or something like that. Also, it is better to just look at the name and know immediately that it is not a core class.
Another thing I want to bring to your attention is that: while working with ZC, I found that it can be ridiculously difficult to completely remove a plugin since even if a plugin does hack into any core file it still have many files in various locations. Thus, I propose, if it’s not already so already, that all plugins files should be store like this:
plugins/plugin_name/
The under it you can have various folders such as modules, languages, templates,…. with the same structure as the current zencart
The point is that it will be much easier to completely remove a plugin, and keeping the same structure as the current zencart will avoid having to write too much new code
Comment by Raine — November 25, 2009 @ 6:06 pm
Hmm, might be an idea. I just don’t want to end up with ridiculously long class names.
I guess some sort of other prefix for plugins might be an idea. One reason to bring this up again is that I currently have a case where a client needs to extend a plugin class. The alternative would be to clone the whole plugin which isn’t ideal either.
Not sure how much you’ve looked at ZenMagick plugins yet, but the ‘one folder to contain all’ is exactly what is happening.
The zen cart override system – while working – really is a pain, in particular working remotely.
So far views, etc are pretty much limited to admin pages, although some plugins (like the wordpress one) do allow to user store views from within the plugin.
Comment by DerManoMann — November 25, 2009 @ 9:13 pm
I plan to jump ship to ZM as soon as I finish all my current Zen projects. I read about your blog post with admin new theme option etc, that is really cool. The thing I hate the most when messing with Zen plugins is that there is absolutely no framework to follow when you write the admin part, you can do whatever you want in there and the result is a total mess which is full of hacks and holes.
Keep up the good work. I will try my best to wrap up whatever Im doing here and give ZM a new look for the default template soon as well. I just need to fool around with the code a bit to get familiar with it.
Comment by Raine — November 26, 2009 @ 1:56 pm
Cool. Thanks to you there is a lot of new plugin code in the making (or already checked in). So, take your time. Once 0.9.8 is out might be a good time to look at some of the renovated plugins to get a feel for what is possible and what might be still missing.
I guess there will be an option to toggle between old and new plugin conventions. Obviously, that is not ideal, but should give plugin developers a chance to start working with the new code before it is required.
Comment by DerManoMann — November 26, 2009 @ 9:22 pm