I am happy to announce the availability of ZenMagick 0.9.13.

It’s been a long time coming and it does include a number of good things.

One thin is definitely the extended use of the sfymfony2 dependency injection container.

A lot more framework code changes are centred around streamlining configuration and customization and having a clean system to change the default behaviour will hopefully pay of in the near future.

Finally, the groundwork is in place to tackle a proper checkout API.

I’ve spend a lot of time recently working on some mock objects for the checkout process. The main one is a class called ZenCartCheckoutOrder.

The main idea is that an instance of that class can can be created and given a ZenMagick shopping cart instance would look and feel just like the zencart order class. With this (and some other hickery pokery) an evironment can be created that allows to use zencart modules without zencart actually being loaded. To be fair, this is not archived yet, but it is already used by the module wrapper classes in ZenMagick for the regular checkout.

One of the nice things I added was some assert code to compare a freshly instantiated zencart order instance with the mock object. This effectively means we are comparing pretty much all checkout relevant data as seen by zencart and ZenMagick, respectively.

The result is a much improved ZenMagick shopping cart class that now should cope with pretty much all price/tax configurations.

In the medium term these mock classes should allow us to use those legacy modules without having to load the full zencart stack – this is going to be a bit reduction in overhead. However, this is still some time away, but the light at the end of the tunnel is getting bigger

EDIT: For the worried people I should probably add that if numbers were wrong so far this would have been purely presentational, because the actual order process is still 100% zencart so far. That means the actual order will be the same in zencart and ZenMagick.

NOTE2: In actual fact, the exception to the above note is that payment modules that generate a complex order button form (or url) would be affected by this.

Time is flying when you are having fun, so in that respect is has been a very short week.
We’ve made lots of progress, so here’s a quick summary:

Infrastructure

• doctrine
  Lots of work here – looks like it is almost ready to move into HEAD, at least to provide basic functionality.
• Settings
  We do have a new Settings class that improves and extends the current ZMSettings code. It also now supports imports: – something also found in symfony config files.
  Also, the reorganized setting of config files/locations now also supports environments. The environment can be controlled by:
  • .htaccess
    SetEnv ZM_ENVIRONMENT production
  • front controller
    index_devel.php?rid=… or index_test.php?rid=…
  • define
    define('ZM_ENVIRONMENT, 'test');
• Events
  The event system has been upgraded too, building on and extending the symfony2 EventDispatcher.
• Bootstrap
  The bootstrap code (bootstrap.php) has been slimmed down quite a bit and a few things have changed order to make more sense.
• ClassLoading
  The currents system of auto loading static PHP code (per convention all .php files in the class path with a filename starting with a lower case letter) has been deprecated and removed from the bootstrap sequence and all other places (plugins/themes).

There are a few outstanding items that still need to be tackled for the next release, most importantly Dependency Injection. With the current core.php system already removed from the code base there is definite need to allow plugins and themes to customize core classes.

With the improved bootstrap and settings code the location of config files (and support of local.php, etc) have changed. This will require a little bit of work for theme and plugin authors. For the next release documentation should be ready to guide upgrades and changes.

Bugs

There are a number of bugs that have been fixed, most notably a bug in the zen-cart admin integration, removal of debug code and a couple of edge cases in the WordPress plugin.

The move towards PHP 5.3 has opened a lot of opportunities for using features and libraries that were, so far, not an option. So, consequently, most of my time since the release has been spend on evaluating options.

Some of the results of that process can be found in the ScratchPad. Right now a lot revolves around integrating code via git submodules and trying to get rid of the current system of pre-packaged 3rd party libraries. As an alternative there is already new code that can wrap up lots and lots of code in PHP phar files. Similar to the current core.php stuff, this is a seamless process, so if the .phar files exist they will be used, otherwise the file system will be queries for missing classes.

The new class loader code is already working nicely and is so much simpler than the current one. However, there will be a migration period, so the current ZMLoader will not disappear in the short term.

Since the current overloading system via the ‘ZM’ prefix won’t be supported for all PHP5.3 code (read namespaces), there is need for a replacement to allow themes and plugins to customize core code. In order to do that in a more mainstream fashion I am currently working on integrating the symfony2 dependency injection code. Right now this is beta, but I would expect that in time for the next ZenMagick release things should be stable.

So, bottom line is that there is a new batch of low level tasks to prepare ZenMagick for PHP5.3 and also to use even more 3rd party code.

Finally, observant people might have noticed that there is now a second developer with full access to the github repository. Things will start slowly and I will talk a bit more about that in the next few weeks. Still, welcome aboard, Johnny – I am looking forward to some interesting times

Well, as is usually the case, once a release is done it is time to start looking what lies ahead. We’ve made good progress on getting new infrastructure set up to organize the future development of ZenMagick. That is good for several reasons:

• It brings new people on board
• It will hopefully streamline development, which, in turn, will result in getting more done in less time
• Gives us a lot better integration of the various systems than what we’ve had so far with sourceforge (which might not actually be their fault, but could also be sloppy use of what they offer).

The next big step that we’ve taken with ZenMagick 0.9.11 is moving on to PHP 5.3. This gives us a range of great new options and also a much better choice of 3rd party libraries (like doctrine) to use.

There are a lot things we can do now, for example using proper namespaces, replacing the current core.php system with a few pre-build phar files and a lot more.

The obvious advantage of using existing libraries is that there is less code that we have to write and maintain. Ideally this will happen all within the framework, so regular users that are just concerned with templates should not have to worry.

Getting finally to a point where it becomes clear how things are going to work in the long run also means it is now time to start with some proper documentation. So far documentation was hard to do as things changed just too fast. Reminds me: if there is a good technical writer out there willing to help write some good documentation, please let us know!

ZenMagick 0.9.11 is released – finally!

It’s been a long release cycle with lots of interesting changes and I am very happy to finally have pushed this release into the wild. One thing I think I might have not mentioned before (it’s in the release notes, though) is that ZenMagick 0.9.11 (and all future releases) will require PHP5.3.

Of the changes the one I like most is definitely the integration of the zencart admin pages into the ZenMagick admin UI. it all started from a chat in the zenmagick chat room (xmpp) and some playing around with code. After that things were surprisingly easy and perhaps will be a good example of doing the same with storefront code (using ZM exclusively and loading zencart only where required).

Please be aware that there is a new bug tracker and more that we now use to coordinate development. There is, of course, also the forum for all questions that you may want to ask.

I am sorry to have to tell you that the next ZenMagick release 0.9.11 will be delayed until sometime in January 2011. It wasn’t an easy decision, but there is no way for a thorough release build and documentation  before Christmas.

To be clear, there have been some last minute regression fixes, but nothing major. Its entirely to blame for me to be rather too optimistic about the spare time I would have in the last and current weeks.

So, Merry Christmas everyone – enjoy the break (if you happen to have one) and/or the snow (if you have some and don’t need to travel…)

Despite a bad cold things are progressing – slow but steady! So things are looking rosy for the promised Christmas release (becoming sort of a tradition to release before Christmas, it seems).

I’ve finally managed to fix all price related unit tests and make them pass too! The new date handling code is checked in and really simplifies things a bit. So, if you look at the roadmap for 0.9.11 things are looking swell!

Lets hope that the admin integration work does make ZenMagick attractive for a lot more people – and developers…

I just noticed that the function zen_get_attributes_price_factor() is using a define that doesn’t seem to be set anywhere in zencart at all.
The name of the define is ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL. it seems to control whether to use a special price or the regular product price as base for the calculation at hand. Looks to me as if this has never been implemented properly or it is just an artefact from some code cleanup…

After some conversation in the ZenMagick online chat (you can also use pidgin, Gajim or any other decent IM client, of course..) I started playing around with the view related code in ZM.

A first result can be seen in the screenshot below. [Btw: the theme in the images is the Modern theme created by rubikintegration.com] Essentially it comes down to the following two four lines of code in tpl_index_default.php:

view = ZMUrlManager::instance()->findView($request->getRequestId());
$view->setLayout(null);
echo $view->generate($request);
return;

Of course, this doesn’t really scale well, in particular if the view expects some model data provided by the controller. So, some very crude cut & paste (actually just two lines..) and we have:

$controller = $request->getController();
$view = $controller->process($request);
$view->setLayout(null);
echo $view->generate($request);
return;

As proof a further screenshot: