I’ve created an experimental plugin to play around with PHP Rules this week. It’s small, nice and easy to use. In fact, since its rule class can be configured using setter methods, it would be easy to write simple wrapper classes that translate ecommerce related rules. Examples could be promotional rules like ‘is product xyz in the cart’.

OTOH, once you’ve written that much code to convert the rule ‘is xyz in the cart’ into a boolean value, it becomes trivial to add some and/or logic to tie this up with other ‘rules’ and evaluate that.

Now, it might be possible to leave a lot of the evaluation part to PHP Rules, but then I am not so sure about performance (not so much because of the PHP Rules code, but just because it unnecessarily increases the complexity of the ‘rule’ to evaluate).

Either way, this is probably the kick off for a new plugin to allow to set up and apply promotions based on rules, conditions and such. Still some way to go, though.

There has been a setting isEnableZenMagick in ZenMagick since the very first releases. Initially, it was intended as simple switch to disable ZenMagick completely. However, over time this morphed into a ‘disable themes‘ flag and recently is was a bit broken too.

I checked in some changes to get this working again. To reflect the changed behaviour I also renamed the setting to isEnableZMThemes.

I thought about removing the flag completely. After all, if you want to get rid of ZenMagick, the easiest way is to remove all patches using the installation page. However, it occured to me that keeping the flag might actually increase the potential user base. Reason being that with the storefront disabled, ZenMagick would become interesting for people that would like to use the admin enhancements (for example the Catalog Manager).

Also, to counter the claim about ZenMagick being a Zen Cart fork, the project could perhaps be broken into two packages:

• ZenMagick (core)
  The API and basic admin pages
• ZenMagick themes
  The majority of the code including the default theme, controller classes, etc.

So this is only a thought I don’t even know if want that. It would be a bit of work to get the current build process changed to create two separate packages. I suspect at least some files would need to be split in order to cleanly separate functionallity. Oh well, another item on my list of things to think about.

Since it is now possible to inject methods into ZMObject based classes, I figured I might as well use it. In fact, this is how most new (framework) features come to exist.

So, what better place than to keep improving the unfinished product associations plugin. I decided to attach a new JSON/Ajax method to the catalog ajax controller. Of course, the devil is in the details and I soon found myself fixing some obscure things in ZMBeanUtil and the reflection code in ZMAjaxController to allow it to find injected methods :}

Once that was all sorted I really could use the existing catalog controller to access my new method ! The nice thing is that I do not have to inherit, but due to the fact that the injected method always has access to the original target object, it’s easy to access all relevant data/methods of  the original controller.

And, because it is so nice, another screenshot of the current state of the product picker. The image shows the picker on the second page of products of the ‘Big Linked’ category with one product selected in the current list and one from another category.

As part of my work on the new product picker I’ve upgraded to jquery 1.2.6. So today they release 1.3!

Sounds like a goor release with tons of new stuff. I guess I’ll be upgrading again soon

In a way  this is good, because it means I’ll be reviewing all used JS and try consolidate things a bit. In particular the used plugins should be looked at again. Most use cases are quite simple, so it would make sense to review the available options again and go for the best performing alternative.

Another thing is that I noticed that the catalog manager page doesn’t support injecting header code. This is going to be more important with more plugins coming and each having its own requirements.

In fact, I might change the current system of passing around a ZMPluginPage instance to another service. This would also make it a lot easier to avoid including the same file more than once. It also would mean there is no need to change the admin page .php file for each new plugin that wants to include something different.

Of course, there are also the other usual suspects like IE compatibility. I’ve noticed a few glitches in the category tree and right now, the product picker doesn’t really look that good at all :/

On the plus side, I’ve extracted the javaScript and CSS into separate files, cleaned up the code, wrapped it in it’s own class and generally am finished with the actual UI JS coding.

Next will be a bit more layout and beautification. After that the jquery/plugin review. Suggestions for good and simple widgets are welcome. I’ll be looking at plugins/code for:

• (non-)modal dialogs
• a tree view
• tabs (incl. lazy loading via Ajax)
• a date picker
• other suggestions?

With 0.9.4.1 out of the way I’ll be continuing with some more Ajax related work. Next thing on my list is a nice looking product picker. So far I’ve succeeded in reusing the category tree plus some jquery code to load products for the selected category.

To make things even better I just added pagination support to ZMAjaxCatalogController::getProductsForCategoryIdJSON(), so it will eventually be possible to page through all products of a category using Ajax.

(more…)