Today I spend some time massaging Creole to properly load in ZenMagick using either ZMLoader or as part of core.php.

There were a number of issues I ran into:

1. include and require statements in Creole sources rely on the PHP include_path
2. Some files are missing the closing ‘?>’
3. DebugConnection.php does not include/require Connection.php, breaking the otherwise perfect dependencies
4. Record.php includes a require for QueryDataSet.php which actually creates some sort of circular dependency loop, since QueryDataSet.php also depends on Record.php…

#1 was to be expected in one form or another, so it wasn’t really an issue.
#2 is actually something I do not really understand, but then, I never had the time/energy to read the PHP specs to figure out why this is working at all. If you know, feel free to leave a comment…

#3 turned out to be a problem, because in order to be able to include all files in core.php I had to rearrange all source files based on dependency. A short script that build a simple dependency tree was easily done based on include/require statements, except for this one file (which I ended up hardcoding in the script…)

#4 was really annoying because it meant that initially I had to patch Record.php in order to get all files loaded at all using the include_path solution (which is the documented way of installing Creole!) . Eventually I changed my *import* script to load the files from a non ZenMagick folder, so no initial loading was done.

One thing that might come out of this exercise is that hopefully I will have time to split ZMCoreCompressor into a generic class and a ZenMagick specific subclass. That should allow me to easily build a single file Creole version that can then be included in ZenMagick versions instead of the full 90 odd single files (this is version 1.1). I might strip this down, though, excluding all non MySql drivers as there is currently no point loading them…

One really nice thing I discovered was that Creole follows a concept of filename-classname relationship very similar to ZenMagick. That definitely made it a lot easier!

As a first step of migrating to a more sophisticated database access system I have started with adding a simple layer (read: interface) that eventually will replace all $db usage. The interface will provide some simple methods to read/write the database using a lot of the ZenMagick binding code.

That should make it easy to replace the current $db based implementation with something different. The nice thing right now is that I can migrate services and other database access classes one by one without breaking anything.

Once all code is converted to using the new interface I’ll start investigating alternative implementations. I really like Creole, as it looks (intentinally) a lot like Java and the interface design is done with that in mind, so it will be easy enough to create an implementation using Creole…

I have just checked in some new code that changes the way settings are accessed. While doing that I went through the current set of default settings and started cleaning up.

There are quite a number of unused settings in there right now, so that has to change.

Another thing I realized is that there are actually a number of definitely layout settings. Those are still from the old days and actually they do not fit the ZenMagick philosophy any more.
I think most of them will have to go. I will try to add a simple way to ‘have them back’ for portability. The default theme will change to live without them. Templates will be changed to look like the current templates using the default settings.

As a side note: it is always possible to use the zen-cart defines in ZenMagick. It is not required to use settings. So, it should be easy enough to replace somwething like the current zm_setting('isSiteMapAccountLinks') calls with SHOW_ACCOUNT_LINKS_ON_SITE_MAP=='Yes'

I’ve been pondering a few database related issues lately. There are two main things that bug me right now:

• I am not too happy with the current database code in zen-cart
• The ZenMagick database code is getting at it’s limit right now

In the long term I would like the database code to move towards an existing db layer, for example creole. That would be still pretty low level, but considering the complexity of the current table layout I would prefer something simple and build custom code on top of that.

My vision for the ZenMagick SQL code is to convert that incrementally to:

• Using an existing basic db access framework
• write something smart and custom to generate the SQL with less custom code for each service

I think the second point is actually the more crucial and interesting one

One first step that I have started already would be to clean up the model classes. All methods with actual logic should move somewhere else. Ideally, there would be only get/set methods and even that could be reduced.

The main problem I see right now is that by removing the actual getXXX() and setXXX() methods the phpdoc documentation would suffer. Right now I am undecided what to do. It would be nice to have just a simple model class with 10 lines, no matter how many properties. On the other hand it would mean people would have to start looking at the database tables again in order to find out what a model class actually contains!

One solution would be more code generation based on some meta data. However, that would be something happening during release build, not at the users side (like the core.php stuff).

Any opinions welcome. Some educated guesses as to what zen-cart is up to would be very helpful too!

I just pulled the plug on the old ZenMagick website. All traffic will now be redirected to the new site. I’ll see what is left to move into the wiki. That reminds me – the idea of a wiki collaboration! Personally, I do not need it as I know more about ZenMagick than necessary…

For a current project I joined the growing number of people using CakePHP.  Even though I didn’t use any of the bakery options if found it mostly very useful.

Of course, there is the time spend to figure out how all fits together and I pssobily haven’t even touched half of the features.

One thing that I noticed, though, is the lack of consistent documentation. I mean, there is lots out there, but usually the stuff that breaks is so specific that it really takes a while to find the answer. On the other hand the CakePHP newsgroup was more then helpful for me.

There were two big issues I had so far:

1) Upload progress bar.

Thi si snot really CakePHP specific, but it took me a while to figure out how to tell the controller to not use a layout and view. But then, I usually prefer to read sources rather than read documentation.

But before it came to all that there was the realization that PHP doesn’t really make it easy to do that at all. As of PHP5.2 there is basic support, but even then it requires to install an extension in order to be able to really doe something useful.

Further complications are that the code seems to be less reliable on Windows installations. After some late nights experimenting with the sample code of the extensions author I tried an alternative demo which finally worked.

Still, it took me a ling time to figure out why my upload form wasn’t working when the demo could do it.

Two things really stand out here:

•  The form needs a (hidden) MAX_FILE_SIZE field.
  Interesting is that the value that works is 411353512 which I believe is the default value. It doesn’t matter if PHP is configured differently. Even though I was able to upload larger files, increasing the value broke the upload progress extension (or PHP)
• Each file input field needs a (hidden)  UPLOAD_IDENTIFIER field with a unique value. That value is then used to track progress.
  Again some very interesing things here. First of all the identifier field has to be right before the field input, it’s no use putting them all at the begin or end.
  The secod thing which took a lot longer to realise was that in order to work an additional identifier field was required after the last field input.

2) Session handling

Once I had the progress tracking basically working I ran into the next problem. Even though everything was working fine when doing it manually, tracking progress using Ajax caused the session to expire.

More experimenting showed that parallel or overlapping requests would cause the same problem. So, hitting reload a few times would make the session invalid!

This is where the CakePHP newsgoup kicked into action. After some very speedy responses and quick testing it turned out that the setting Security.level was the culprit.

It seems that recently the code was changed so the high setting would regenerate the session id for each request! that means with parallel requests the session id gets lost!

To sum it all up: I think CakePHP is really useful and does a lot of stuff assuming (rightly so) that most web apps works pretty much the same (login, authentications, sessions, forms, htm you name it).

However, once you need something more individual it takes a while to dig out all the nitty gritty details needed to make it do exactly what you want.

There’s been so much happening in the code base that it is hard to know where to start. One thing is quite clear, though: I really regret making the last release 0.9.0, as the next version is going to be much better/different/incompatible that any previous ZenMagick version.

Do not be afraid, though. Even though there are massive changes, there will be a compat/legacy mode that will allow you to use your existing code (whilst busy upgrading). That means incremental upgrades of template files will be possible.

So what is really changing? Some of the changes are inspired by my current work with CakePHP. Even thought the documentation is definitely better than the ZenMagick one (in particular more people blogging about their experience…) it’s still lacking in places.

One thing is that I already talked about is replacement of globals. This means something like:

$product = $zm_products->getProductForId($zm_request->getProductId());

will look like:

$product = ZMProducts::instance()->getProductForId(ZMRequest::getProductId());

Seems a bit longer, but has some great benefits:

• Right now all services and a few other things are instantiated during the init of ZenMagick. That means that there is always overhead because of globals that are never used (I do not think that all services are ever going to be used in a single request).
• Overloading of service classes is not possible (at least not in a way that fits into the ZMLoader concept)
• Ensuring that all globals are available always and everywhere just is a pain
• Plugins that add new services are left out of the loop (unless thy use the zm_ prefix which external plugins should not do!)

Looking more closely at the code it turns out that ZMRequest does not need the instance() method as all methods are real static methods. The general rule is that services do require the instance() method, ZMLoader, ZMRequest and ZMRuntime are just container for static methods (while using an instance internally).

I also started moving a lot of core functions into the appropriate service class where possible. Other things will follow. One thing in CakePHP I particulary like is the helper concept for HTML generation, so I coud imagine something similar, rather than having all those zm_href, zm_form, etc functions.

Moving functions into new classes making them semi-static also means it would be possible to allow to replace those by providing a custom class implementation same as with *normal* classes.

During all those style updates I also managed to strip the init code a lot more, so some speed gain is to be expected.

Last but not least, more improvements to plugins and even a new one!

Not sure if anyone remembers that some time ago I moved all the caching code into the zm_page_cache plugin. That is, all code but the class ZMCache. I was reluctant to move that class as ir provides some basic caching for everyone to use.

However, right now I am in the position to need some caching and it turns out things are not that simple. Well, maybe they are, but it’s not as nice as it could be.

There are mainly tow reasons:

• If each plugin is responsible for it’s own caching only, there will be a growing number of Cache Manager plugin pages, one for each plugin.
• Should there be different caching options (file, memory, etc) there is no easy way for a cache user to take advantage of that. Even worse, it means ZMCache is right now bound to doing file caching.

To remedy this situation and to bring caching more in line with the service infrastructure I’ll be adding another service ZMCache (unless the plural of cache is caches!). This is going to be a cache service that can be queried to get a cache instance that will be what is now ZMCache. I would expect the current ZMCache class to be renamed into something like ZMFileCache.

Another advantage will be that there is no need for individual cache manager pages and it will be much easier to show more cache stats without having to modify each and every plugin that uses caching.

Also, this might be a good way to use more caching in ZenMagick core. For example, some of the more time consuming things like validation rules, etc could be serialized and cached, rather than building them from scratch for every request.

Other thoughts?

If anyone out there is thinking about using Hover Box3, now is the time. I just checked in a new plugin that implements this.

In fact, it’s not just a support plugins, but the complete code. That means it’s now even easier to install than using the zen-cart version.

Again, another good example of what a ZenMagick pugin can do to make your live easier.

Product features are a unique ZenMagick, well, feature. They allow to attach features to each product (for example, size, performance, whatever) and can be compared.

Since they are somewhat limited right now and not very widely used I decided to move the code completely into the zm_product_features plugin. Hopefully this will give me the motivation to start working on it again and add a few things that I have had on my mind or quite some time.