In ZenMagick there is a convention that the key to request a class instance from the DI container is to be the class name  of the implementation expected.

This is not quite in line with other projects and I’d like to briefly outline why things are as they are.

The migration from the prefix based class resolution to a container based dependency injection system is a long one. With the old system the loader would take care of deciding which class to instantiate. Now, the dependency container needs to know all sorts of things before it can do that. Most importantly, though, it won’t work if there is no default configured.

Now, to avoid having to build a exhaustive DI config file right away I decided that by using the class name as the key, the container can default to implementing an instance based on the key if no definition is found. This means all code can start using the container and once a definition is there it will be used. If not – the default will be used.

The only downside of this system is that it is not possible to guess the scope (prototype/container). To fix this during the migration time a method getService() was added to the container class that guarantees that the returned instance is a singleton with container scope.

I expect that this method will disappear with the next or second next release, so do not rely on it. Deprecating and removing this method will require to add definitions for at least all classes used for those getService() calls.

In addition to the above we will be adding aliases for defined services, so eventually the lookup can be done either way. However, use of the alias is the preferred style.

The main advantage of aliases (or, better, symbolic keys in general) is that it decouples the lookup from the actual class (even the default one). Seeing that we are planning on using PHP namespaces throughout the  codebase, not using the alias might eventually break things, once the default class has changed name.

Having said that, the code to default to the key as class name is not going to disappear in the foreseeable future as it is useful in itself, even if aliases are to be used for known services.

UPDATE: One other thing that just occurred to me is that with symbolic names it is possible to use them in bean definitions as well. Good news because that will obsolete a few more settings that deal with implementation classes and will make the code using those definitions much simpler.

Today I changed our submodules to use the symfony vendor libraries where possible (doctrine, swiftmailer).

In addition I’ve added a bin/vendor.php script similar to the symfony vendor.php script. In addition to loading / updating our remaining submodules it also updates the symfony vendor libraries that we  need.

Right now the only thing broken seems to be swiftmailer; symfony is using 4.1.0RC1 and that somehow seems broken in ZenMagick.

To make things easier for people that might want to keep up with current development I’ve created a new wiki page that documents the steps required from a vanilla zencart installation to a working ZenMagick.

Today ZenMagick 0.9.12.1 was finally released!

It’s been a long time coming and I am really happy with the result. Its the first release with input and contributions from more than 2 developers and I really appreciate all the time and thoughts people have put into this release. (Of course, developing a live site on trunk kind of makes you really interested in getting things done …

So, grab it, upgrade, start from scratch and let us know what you think.

I am pleased to announce the availability of ZenMagick 0.9.12 RC1.

In comparison to the previous snapshot, there have been fixes to the coupon code and all missing packed libraries are now back again.

Download: 0.9.12-RC1

Upgrade Instructions

• Uninstall all file patches via the ZenMagick Installation page
• Delete the zenmagick/lib folder (this is to avoid having old files sticking around)
• Delete all local.php files (apps/admin/lib, apps/store/lib, themes/demo/extra) – zenmagick/local.php is still supported, but deprecated
• Update/upload new version
• Re-apply all file patches except the one about replacing zen_date_raw (there should also be a message about that)

I finally managed to upload a new ZenMagick snapshot. Its in the snapshot folder under 0.9.11+.20110616.

No release notes / upgrade instructions yet, so the simplest way is to just install the full version and try that with the available themes.

The snapshot is pretty much a first release candidate, so things are not going to change dramatically from here on.

For a mostly complete list of changes you can check the roadmap for ZenMagick 0.9.12. All issues are resolved, but quite a lot are not closed yet, so don’t get confused by the overview…

As part of my daytime job I’ve had to look at a solution for uncompressing RAR files using Java. There is a nice library out there, even though it is hard to find: java-unrar.

The only downside of java-unrar, as far as I can tell so far, is that it only works with files (java.io.File). For this particular project I needed something that works on an input stream, though.

Research quickly showed that others have had similar problems. Unfortunately, I couldn’t find a good solution other than using temp files, etc. After some more research I finally found ImageJ, a library for – you might have guessed – image processing. However, this library includes a nice helper class: RandomAccessStream. This class implements exactly what I needed.

So, what I ended up with was changing java-unrar to not only accept files, but also instances of IReadOnlyAccess, a simple random access interface. Using RandomAccessStream it was simple to implement.

So far this seems to be working well.

ZenMagick in its current form supports both yaml files and pomo files to store language strings. While I think this is good it also creates problems that are, right now, unsolved.

The main issue is that you can’t mix both. With admin using pomo and storefront yaml this causes serious issues for plugins that have to work in both environments.

I’ve created a few tasks for 0.9.13 to track progress for these issues, but since then have come to the conclusion that concentrating on a single system would be much better. With that in mind I had a look at the symfony2 locale component. symfony also uses yaml, albeit in a more sophisticated form. Although that would possibly be all that is needed to get a single codebase for language strings going it leaves the issue of compatibility and the option to host/manage translations in an open shared environment (for example something like transiflex).

For that reason I think it would be best to concentrate on pomo. The code is all there, lots of resources exist to deal with .po and .mo files (poEdit, etc.). The only bit missing would be something that makes it easy for store owners to manage strings without the need to download and learn new tools. Raine pointed out a great looking WordPress plugin that does pretty much what we need.

So, rather than writing more code to try to support inferior formats it might be a lot more fun to try to port this plugin to ZenMagick and have the best of both worlds.

It’s been some time – maybe too much time since my last update and I promise I’ll try to get better at posting updates again – so here goes…

Since the last update ZenMagick has gone through a cycle of fixing of regressions and generally trying to keep up with changes in symfony2.

Right now there are no outstanding tasks other than testing plugins. This might take a bit longer as some plugins are harder to test than others and I do not always have the right environment ready.

Also, there are still regressions in some plugins caused by the loader changes that now require more proactive code in the plugin to tell ZenMagick about custom classes. The plan is to get the class loader changes complete as part of 0.9.13, so after that things should be pretty final.

There is already a growing number of tasks for 0.9.13 and with all the delays of getting the release finished it is always tempting to sneak in a few more things (thus adding to the delay…). I’ll try to keep that to an absolute minimum and only bugs/regressions will be added from this point on.

I will try to make a snapshot available this week, however plugins have to used with care as there will be some still broken.