I feel it is about time for a new release. I have been quite busy and actually I am quite pleased with the results so far.

The work on this release has not been very structured – I think I should perhaps start making plans for new releases and at least try to stick to that.

On the other hand, there have been so many changes and dependencies that it would have been very hard to follow that plan for 0.9.1 to be.

I am now in the final stage of actual changes – thanks to Matt who opened a whooping 21 tracker in on session this has proven to be a bit longer than expected It’s great to get feedback and there are a few really good observasions in those bug reports and feature requests.

The last thing to be added is something called toolbox. The original bug that started this is about inconsistencies in when and how text is HTML encoded/escaped. Another issue that came up a few times lately is the fact that it is not very easy to customize the code in the html and html.defaults packages.

To solve both of these issues there is now the new toolbox. Basically, it allows to register objects (via local.php or similar) that then will be available for all templating code to use.

Most code in core that generates HTML or any other output that is used in templates is now available in two different ways:

1. There is a new variable $_t that can be used to access all registered tools.
2. Tools will also be available via their name (see examples further down)

The toolbox contains 4 build in tools that are going to replace the current set of html (and related) functions:

• html - Everything that actually creates not just text, but actual HTML (single tags only)
• net – All href helper
• form – HTML Form specific tools
• macro - Container for all functions that are currently under html.defaults

The advantage of using classes is that now it is possible to replace existing methods rather than having to copy and rename functions.

For example, rather than writing:

<?php zm_secure_href(FILENAME_LOGIN); ?>

one can use now:

<?php $_t->net->url(FILENAME_LOGIN, '', true) ?>

or:

<?php $net->url(FILENAME_LOGIN, '', true) ?>

Explanation: I have merged zm_href and zm_secure_href into a single url(..) method (same for zm_form and zm_secure_form). That explains the additional two parameter (params and secure/unsecure flag).

It is also possible to register new tools by doing something like:

<?php

$mytool = new Foo(); // or ZMLoader::make(‘Foo’);

ZMToolbox::instance()->set('mytool', $mytool );

?>

In templates the object $mytool is now available as $_t->mytool or directly as $mytool.

I also reviewed all converted code with an eye on HTML encoding and improving the documentation. My tests do not show neither loss nor gain in performance, so all should be good.

All existing functions have been marked as deprecated and are converted to using the toolbox. That means even when not upgrading an existing template to use the new variables, the new code will still be used.

Only thing left is to convert the default and demo theme to using the new code, but I think I can do some automated rewriting that should help a bit.

I am (again, again, again) agonizing over ZMCategories.

As part of the database code changes I am reviewing all services and model classes and there is heaps that could be improved (from a coding point of view, most of this work won’t be visible to regular users that just mess with templates).

There are actually two things that make this rather tricky:

• Internal caching
  The current implementation does a lot of internal caching in order to be fast.
• The active flag on categories (via applyPath(..))

Initially caching was not a big issue until I added support for multiple languages. Now that I want to add support to create and update categories (for admin tools) there is a second dimentions: the status. Further complications are that the code builds a tree structure to support the category tree navigation.

The second is actually just something I’d rather implement differently as it depends enirely on the cPath request parameter and that shouldn’t interact with a service.

So, I plan to change two things:

1. The meaning of the method isActive() in ZMCategory will change and be similar to the same method in ZMProduct.
   Active categories are visible in the store, inactive aren’t.
   This should actually not be a big issue as this method is used only in the default categroy rendering method zm_build_category_tree_list().
2. The whole logic currently done by ZMCategories::applyPath() will have to go somewhere else. Again, potentially the only code affected is zm_build_category_tree_list().

Any objections? – let me know…

EDIT: As it turns out,  changes are really confined to zm_build_category_tree_list(). That means unless your theme uses a custom version of zm_build_category_tree_list() there is nothing to fear

It’s been a while so I think it’s time to write up a few things that currently occupy some bits of my mind.
1) Donations
I promised not to write about this any more, so just a big Thank You to everyone that that showed appreciation of what I do

2) Making use of all the architecture work I put into ZenMagick
Today I had the chance to show off some of the framework features that make ZenMagick tick. Involved are:

• Event handler
• Custom validation rules
• Use of services to update account information
• Best of all: no changes to core files!

The problem was to:

1. Enforce collection of a phone number during guest checkout
2. Default the first/last name of the guest checkout to the shipping (or billing) address

If you are interested in the single file solution to this check out this thread on the ZenMagick forum.

3) The database work in progress

One sideeffect that I haven’t talked about is that the new code will force me to finally add all the missing setXXX() methods to model classes. Yay! Also, since the changes will make use of automatic table <-> model mappings we’ll get update functionallity for all sevices pretty much for free!

I hope that being able to create and update data in the database will make the API even more valuable (I know that there are a few people out there waiting for this…)

 4) Backwards compatibility

I have written about this before, so just to reinforce the message: 0.9.1 will be, using a single setting, mostly compatible with 0.9.0. Mostly, because there are a couple other changes (zm_product_href got another parameter, for example) that will require some minor changes. There are also a number of functions deprecated – I think I’ll add another setting to log/backtrace using those. That should make upgrading a lot easier.

5) Framework

There are actually still things that I won’t be able to do in a single release cycle. One thing I’ve been dreaming about would be to extract the actual core framework and make it a separate product(?).

The value of doing that would be to be able to concentrate entirely on making the framework as good as possible without the contrains of an actual application using it. I suppose that is something that could happen once ZenMagick hits the 1.0 version mark.

Writing a database abstraction layer is definitely not something I had in mind when stating ZenMagick On the other hand I really enjoy this sort of work – in fact much more than working on new store features.

So far I have a single interface ZMDatabase that will eventually be used to access the database. Right now there are two implementations and the implementation class is configured via a setting.

The interface is not complete yet, I’ll add stuff as a go through the code and convert database access. Currently there is only ZMManufacturers upgraded to use the new code and it works perfect.

Only worry right now is that Creole may throw Exceptions. In itself that is not a problem – is’s actually a nice change to know whether things have worked or not. However, currently none of the code is the least exception aware.  I probably should change that before going to far down that way to avoid having to redo a lot of changes.

I just fear that by starting that can of worms I’ll end up rewriting most of the current dispatch code in order to properly handle exceptions throughout the request process… Oh, well, one step at a time…