Comments on: thoughts on the ZM class prefix

By: DerManoMann

DerManoMann — Thu, 26 Nov 2009 20:22:52 +0000

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.

By: Raine

Raine — Thu, 26 Nov 2009 12:56:37 +0000

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.

By: DerManoMann

DerManoMann — Wed, 25 Nov 2009 20:13:51 +0000

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.

By: Raine

Raine — Wed, 25 Nov 2009 17:06:23 +0000

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