As you can tell from the more recent posts, a lot revolves around plugins in ZenMagick.
With the core store functionality pretty much set (except for the database access code and the service classes that use it), most new stuff happens in plugins.
I have started building plugins that build on top of others (optionally) and that creates some new challenges. A good example would be the token service and the (still to be released) auto_login plugin which will be able to use that token service to avoid having to store the users password (even though it is just the hash) in a cookie.
While it is possible to write conditional code for this (and have plugin config options), there are cases where this does not alwasy work so well.
Two examples are test cases and cron jobs.
At the moment unit tests and cron jobs (I think there is currently only a single plugin that offers that) are included in the plugin package and typically are resepectivley located in a tests or cron subfolder.
While this works good with the cron and tests plugins installed, there is one case where things break: core.php.
Currently, a plugin would check in it’s init() method if the tests or cron and depending on that load the plugins test and/or cron classes.
In the case of using core.php, this is decrepit as all classes will be loaded in any case. This can create conflicts if the test and cron job base classes are missing.
With the current loader code I can see a few possible solutions here (none of which I really like):
- Optional plugin code could be stored in files with a different extension.
The loader would need some more code to allow to register class files with different extensions
- Move those classes somewhere else
- Provide optional dummy base classes in core
With the first option, things become more complex without a lot of benefit. Also, I’d have to figure out how to enable syntax highlighting in vim
The second is perhaps ok for tests, as there could be a separate group for plugin tests in the test plugin. However, that means to split up the code into different plugins which is not very pratical. Also, in the case of cron jobs it’s even uglier.
The third option is the worst and I just list it here for completeness. Adding code in core that is plugin specific is definitely not something I’d like to consider at all.
So, at the moment the first option seems to be the best in terms of keeping things separate and also using existing features (the loader in this case), even at the cost of additional code to support this.
If anyone can thing of other ways of handling this I’d be happy to hear those. However, considering that there is only a single third party plugin I won’t hold by breath