As some might have figured by now, most of the work on ZenMagick is on the actual framework these days.  One aspect I thought I was finished working on are URL mappings.

However, while working on setting up the new mappings to use the new search controller I realized that there is a lot of redundancy in the current way and also in the proposed new way.
All mappings for a singe page ($page parameter) share:

• $page itself
• the controller (if set)

The reason is that all other values like viewId, view, etc. all depend on the controller being executed first. That means there is nothing stopping you to set up different controller for different view and viewId values. However, the mapper will always use the controller set up in the first mapping, and rightly so!

So, to be precise, all mappings for a single page should be set up in a single mapping. In fact, that is what the url mapper does internally. I’ll have a think about how to do this best – maybe it is time to start thinking about reducing the number of different confiugration/settings file formats while I am at it…

EDIT: This pose is thankfully obsolete due to the magic __autoload function!

So far all code [classes and interfaces in particular] in ZenMagick rely on the loader to ensure that extended classes and implemented interface used are loaded. So far this has worked quite well.

Reasons for doing this are:

• Late binding of the actual implementation of classes
• Having a central place that handles file loading
• In case core.php is used (merging all code into a single, stripped file) all that is not necessary

Obviously, there are downsides as well:

• The loader relies on hierachical directory structures to determine the order of loading files;
  For example, if class B extends class A, then the file containing class A (A.php) needs to be at least one level higher in the directory structure than the file containing class B (B.php).
• Unresolved classes throw unrecoverable exceptions in PHP. This is very unfortunate, because being able to handle those would mean it would be possible to recover at least those in case the missing class/interface is available to the loader.
• Some more that elude me right now

The next release will, for the first time, include core files that actually use ZMLoader::resolve('classname'); before the class declaration in order to avoid unloaded classes/interfaces. I o not realy like this at all, but unless I start reorganizing the directory layout (again), there is no way around this.

I happened to notice a  search ‘when is zencart 2.0 actually coming‘ in today’s log. It’s a good question. Unfortunately I do not know the answer, but I do know that the next ZenMagick release is not far!

Today I checked in the final changes to make the category pages use the new sql based pagination code that hopefully will be on par with the way Zen Cart handles it [(except for being a lot more complex, of course ].

That means that the last bit I was hoping to get into the next release is actually in place. I’ll be doing some more testing and try to figure out which plugins need updates. That should hopefully get me to a point where I can write release notes and build ZenMagick 0.9.5 next weekend!

I think I really need to do something about the plugins. Ideally, they would all have their individual changelogs, but right now with core changes that affect pretty much all plugins that seems to be overkill. I guess for 1.0 that might be something to look into, though.

Coming back to the search mentioned above: Of course there is no need to wait for Zen Cart 2.0 in order to enjoy things like:

• Plugins that do not require file changes
• A simple template structure that does not need include/require
• A database API incl. DAO‘s, transaction control and support for different database providers
• A MVC based framework
• Flexible form validation with rules to change both JavaScript and server side validation in a single place
• Guest checkout aka. checkout without registering
• and a lot more

Just start using ZenMagick today!

With the number of things on my todo list for the next release shringking fast its time to have a look at what is about to happen in the next ZenMagick release.
I’ve already written about a few things, but I think it is also nice to have it all in one place. (Also, these posts are usually good starting points for writing the release notes!)

So, here’s a list of things to look out for int he next release:

• Banner Management
  So far, banners where identified by index (integer) and needed a setting each in order to work. As of 0.9.5 this is going to be simplified and there is actually already some documentation about how things are going to work.
• Database API
  A number of things changed here, in particular the ability to create type mappings on-the-fly and support for array model data in all xxxModel() methods should make life simpler in a few cases
• define refactoring
  A lot more defines have been converted into consts in the appropriate classes. Defines are fine, however, I feel that consts are a lot more readable and also it’s easier to find where things actually are in the source code.
• ZMLayout refactoring
  The service class ZMLayout has been renamed ZMTemplateManager in reflect the newly added methods to manage CSS and JavaScript resources. Short story is that it allows to add CSS to a page even after the <head> section has been created by the template.
• Support for large result lists
  I’ve explained this already, so I’ll just say that the new solution is SQL based and pretty close (at the bottom) to what Zen Cart currently does.
• Plugins
  As usual there will be new plugins. First, an initial version of a plugin to manage custom ZenMagick settings in the database. It uses some new widgets and I expect that with the number of widgets growing there will be a lot of improvements in the future.
  Secondly, support for phpBB3 at the same level as currently exists for phpBB2.
  There are also improvements and fixes for a number of other plugins that are, of course, listed in the changelog.
• Open
  A couple things are still open, but should be included, time permitting: a new search page based on the already existing ZMProductFinder class, make all unit tests pass!

I am currently going through all unit tests to slowly prepare for the next release. Since all tax service tests failed for a while I decided to see what that was about.

(more…)