I’ve been working on yet more cleanup of the startup and init code to move closer to a framework that is generic enough to be used as general PHP framework.

While this is not a top priority, it’s something I enjoy and that also add value to ZenMagick (well, most of the time).

The improvements to the loader have also helped reducing the code in the main init.php file. Although the code got removed from there doesn’t mean that it completely disappeared, though. A lot of it ended up in ZMEventFixes, which now is more of a shopping cart init class rather than just a bunch of things to run in order to make zen cart happy.

The more time I spend on all this there more it feels like each theme is, in fact, a separate application. The only important difference, however, is that they can (and do) depend on each other. Ignoring that for a moment, what do we then have left?A number of themes,  one active at a time (unless using the multi site plugin to allow different domains to point to different themes).

I wonder if eventually it might become feasable to have the webserver’s document root point to a theme folder and really treat each theme as a separate application using the ‘ZenMagick framework‘.

Obviously, the name theme would then not be appropriate any more. Still, all of that is far in the future. One thing is nagging at me, though and that are the theme info classes. Currently, they do not add a lot to the overal architecture. Also, except for the layout settings (specifying that default_layout.php is the default layout file, for example) there isn’t really a lot in there that is still used I’ll have a good think about removing some of it.
In particular the code related to JavaScript does seem a bit old fashioned and with jquery and Co. around, there isn’t much point in configuring JS for each page any more.

About two years ago I wrote a post Is ZenMagick for you? This post is an updated version which is supposed to put things into perspectice, in particular the current status and future plans. (more…)

A while ago I wrote about the loader and how there were still a couple pieces missing to make loading really useful.

As it turns out PHP has an answer for my question and that is __autoload(). I’ve read a little bit about this special method [or hook if you like] but then forgot about it again. Having a better memory would have saved me a few hours, I guess

The __autoload() function allows application code to make one final attempt at locating and loading unresolved classes/interfaces and functions. Adding this function with a simple call to the loader was all needed to make everyone happy and remove the need to call ZMLoader::resolve('CLASSNAME') to be able to safely use CLASSNAME.

However, things were not quite as easy. The loader uses a lot of class_exists() and such and (obviously) those trigger another call to __autoload()! So, I’ve rearranged the central code in ZMLoader again and actually it is a lot more readable now [and perhaps even a bit faster too!]

The most satisfying bit of the whole excercise was removing the code that preloads a range of classes to be able to use the service classes right away. Also, in places where explicitely classes with the ‘ZM‘ prefix are used it’s now possible to use PHP’s new operator rather than the more convulated ZMLoader::make('CLASSNAME');.

Perfomance doesn’t seem to have suffered from this change and in some case might even be better (at least when not using core.php). And while I was at it I added some simple stats to the loader and extended the zm_page_stats plugin to display those. It’s rather basic and consists just of the number of static and class/interface files loaded during a request. Still, interesting to compare different pages.

… or, things to come II

For the last few releases I’ve been bumbling along, changing whatever I fancied and never really worried about anyhting. The closer ZenMagick moves towards a 1.0 release, the more difficult it becomes to continue doing that.

There is a long list of things I want to do and also a list (not on paper) of things that I think should be in 1.0. There are two things I really should get done to give the releases a bit more direction and also (re-)assure users that there is actually hope to get to a 1.0 release at all!

1. Prioritize the visions list and split it into two listsl; one including things that will be in 1.0 and one with things to come.
2. Eventually I’ll have to face the fact that after a 1.0 release I’ll have to spend more time doing proper branching in order to keep the APIs stable for a while. At the same time there should be work on future versions with new/changed APIs and stuff from the visions list that didn’t make it into 1.0.

I guess one reason why it takes me so long to get there is #2. Branching and maintaining several branches (for example a 1.0.x branch and also a 1.1.x branch) is not something I am particulary looking forward.

in conclusion, I will try to start working on a more substantiell roadmap towards a 1.0 release and put that on the wiki once it is fleshed out enough to be of any use.

Even though it will be some more time before the next release I’d like to write a bit about what is going to hit the shelfes in the future.

Form Handling

As already mentioned, there are going to be some major(ish) changes to templates. More specifically, fomrs and form fields. Due to the fact that form submissions [except for the checkout] are handled by ZenMagick code, it’s now safe to change the names of form fields.

Why would we do that? Well, getting the form field names and the property names of the model objects feeding them in line seems like a good idea. It also makes it a lot easier to move form handling onto the next level of using generic code rather than specific code for each form.

This change has had more severe consequences than I expected, though. For one thing, form validation changed a bit and a lot of controller that now take advantage of the new code.

Another area is url mappings. All build in forms that ZenMagick handles are now configured as part of the url mappings. That means that controller do not need to create, populate and validate form objects themselfes, but can rely on the fact that processGet() and processPost() are only called if the form validation (if configured) was successful. All that is left, is to call $this->getFormBean() to retreive an object containing all relevant form data.

One particular improvement in that context that I was looking forward to, was that now the state (text input) and zoneId (dropdown) are now properly separate fields which makes some things a lot easier during processing. No more guessing as to what the actual content is.

Toobox

There are more changes/additions to the toolbox to further centralize all helper code that templates ever need in there. Obviously, there is still room for improvements. The next steps will be a new element to help plugins and probably another one for admin pages (obviously there is some overlap between the two).

Plugins

I’ve written recently about some new plugin ideas, but there are a number of still unfinished plugins in the repository and it seems it is about time to get some of those done. A quick browse brings up the following:

• product associations
  A generic association plugin. The focus has slightly changed recently, with a new idea being that there could be a generic association framework (presumably in core) and plugins that can add some sort of data source to drive relationships between products.
• product features
  This really needs some time to get up to speed with recent changes and to make it actually work again as it was, before even trying to attempt improving it!
• promotions
  There are some concepts and ideas, but not a lot of code yet. The basics are rule based promotions (perhaps realized as order totals) to allow discounts, etc
• surcharge
  This is almost complete and will add another class of plugins to ZenMagick, namely order totals! Based on regular expressions it allows to add surcharges based on checkout data (right now this is used to implement a surcharge for certain credit cards).
• dev tools
  Collection of developer tools. The language tool is one candidate to move there, as are a few things like a database table mapping generator and other useful stuff
• affiliate
  There is a nice affiliate mod that I’ve started converting to ZenMagick. Most of the storefront is done, but as usual, the admin side takes time – if anyone is keen on plugin UI development, please let me know!
• redirect/forward
  As described in my other post about plugins.

Other stuff

There are the obligatory bug fixes, some more cleanup and removal of deprecated code. The plan is to move all deprecated code into a separate plugin to allow people to upgrade while continue to use that old code. Most likely the legacy settings will move there too.

I’ve been playing with some new code that allows ZenMagick plugins to act as order total. Looking at some of the existing order total code I am a bit wary that the modules operate on an order instance.

I think it is quite handy in that the same code will work on actual orders. However, it feels a bit forced. Considering that for plugins that want to be order total modules there needs to be a new interface anyway, I am tempted to change that to operate on the current shopping cart instead.
With the way order totals are stored I can’t see a lot of value in this anyway, as populating an order total module from a saved order is naturally quite different.

This thought lead me to my next questions: currency? The tax module, for example, uses the currency set on the order to format the value. In ZenMagick this is stored/retreived from the session object. It might be useful to add convenience methods on the cart to allow looking up all related information from a single point. It would also mean that the session would not need to be exposed to templates at all, since the cart is available pretty much everywhere [or via ZMRequest::getShoppingCart()].

Obviously, ZenMagick plugins itself would not use any globals to evaluate their value, nor should they modify the cart. Instead all required information would be collected and then applied in a central place. if there are examples where this approach would not work, I’d be happy to hear about those.