Form validation rules
Since it is now possible to either add or replace validation rules for a given form id, there is a pitfall in that plugins typically set up their custom validation rules before the global/theme validation rules are loaded. If a theme developer decides to override the default rules for a form those plugin rules might get lost.
For example, a particular site might not require a date or birth, postcode, etc. and it might be easier to replace the default rules with a new (smaller) set of rules.

To avoid overriding plugin rules I’ve started converting plugins to use the onZMInitDone() event callback to register custom validation rules. This event is fired once al bootstrap, init and theme setup is done (right before the controller gets executed).

Database auto mapping

I might have written about this as part of a release announcement, but I can’t really remember, so here goes (again)…

Most All ZenMagick services and other classes that access the database use manually created mappings to map object properties to database columns. These mappings are store in the appropriately named file core/database/db_mappings.txt. The mappings also contain information about data types which are used to properly bind values (ie. cast to int, boolean or quote to name just a few).

Sometimes it is not practical to create mappings in advance. In particular if the exact format of the table is now known. In those cases the ZenMagick database API can generate a generic mapping on the fly to ensure type safety. One good case where this is useful is to access 3rd party databases/tables (the new phpBB3 plugins will make use of this).

Currently this is disabled. To enable just change the value of the setting ‘isEnableDBAutoMapping to true.

There is constant interest in my last post about phpBB support. Seeing that phpBB2 is getting a bit old and phpBB3 the way to go I decided to have another stab at phpBB3 integration.

Rather than write just some straight SQL I’ve played a bit with using phpBB code directly from a plugin. Had I seen earlier that phpBB3 also uses a global $db (same as Zen Cart) it might have saved some valuable time :/

Anyhow, I am happy to announce that some critical progress has been made and a solution is within reach. There is working validation code (email address, nickname) and yesterday I managed to get the create account code to work.

The trickiest bit was actually to get the password hash to work. Since the phpBB code needs database access (no, no, $db!) I had to find another way.

Luckily, the hash code in phpBB is based on phpass without any major modifications. So, I’ve added phpass to core (just the one class PasswordHash) and added a generic new authentication provider using it.

The new phpBB3 plugin will have its own implementation,. though, as it needs to generate hashes with a different identifier. Yay!

Next on my list are updates and logoff. In the long run there might also be code to handle session timeouts and auto login to phpBB, but I haven’t done any research on that yet.

So far, like most integration mods/plugins, this is one way only (from ZenMagick to phpBB). If anyone could point me to a phpBB mod that tracks user actions (registration/modification/logoff) that I could use to implement the reverse (profile changes in phpBB) that would be great.

Yesterday I landed some code changes that will should show major performance improvements browsing large result lists.

Result lists together with filter and sorter options are managed by the class with the obvious name ZMResultList. So far, sorting and filtering is done in memory. While this allows for simple code to add sorting and filtering options, it also means that all items of a list need to be loaded first.

For small stores that is not really a big deal. There is a reasonable amount of caching going on in the service classes that provide access to the database. Also, with small lists the performance is as good a SQL based sorting, filtering and paging. Now for large catalogs this is not acceptable and in fact means that ZenMagick in its current form is unusable.

The way the new code works is to allow service classes (actually, any class that provides database access) to implement a new interface ZMSQLAware. When a result list is set up the code will check for implementation of this interface and if it exists, use the method(s) defined by that interface to do SQL based paging. This is similar to the way Zen Cart works now and in fact some of the code is based on that.

The next step will be to change the filter and sorter code to also be aware of SQL to have a full SQL based solution.

Today I’ve checked in support for sorters and filters! Right now, the only service to support this is ZMOrders (incl. a new order sorter (date and status) and filter (status).  The filter is not yet done properly since the code currently depends on request parameters. So among other things I’ll be reviewing all of that (for both sorters and filters) to make them request agnostic without having to write too much code.

After that is should be pretty easy to add support for other services, sorter and filter…

I was recently asked if I’d be interested in reviewing a book about Zen Cart. Since I’ve never read a book about it I figured that that could perhaps be an interesting experience [Usually, I prefer to read the source].

The name of the book is Zen Cart: E-commerce Application Development, written by Suhreed Sarkar. It’s available from the original publishers site at Packt Publishing and also from the other usual suspects.

The book is mostly aimed at people considering starting an online business but also developers and existing Zen Cart users that want to improve their business. For my taste some of the book (in particular the introduction) are a bit to long winded for more experienced readers, but I guess that can be said of a lot of books.
Still, it will give beginners a good idea about what Zen Cart (and e-commerce) is about. Since there are so many different aspects to Zen Cart [and therefore this book] I’ll follow the book’s structure to organize the review, so here goes… (more…)

There is a reason that it has been quiet for a while around ZenMagick. I’ve got a new project:) Nothing too serious and most likely not even a real project.
I’ve tried adding some new features to PHPDoctor, the PHP documentation creator that I use to generate the ZenMagick API documentation. Since it turned out to be a lot messier and complex than expected (perhaps due to my inability to understand the code, I might add) I started re-implementing everything (but not from scratch).

(more…)

Yesterday, I wrote about the new getBean(..) method in ZMbeanUtils. Today I checked in the changes to allow bean definitions in url mappings. This required some restructuring of the parameters (incl. renaming of some of them, plus dropping the parameter parameter, which is no longer used now that parameters can be specified as part of the class).

(more…)

A couple more bugs have been found which must have been around for a while, actually. Not sure why noone picked those up or reported them, though.
Anyway, just a friendly reminder that it pays off to keep an eye on the bug tracker. Even if bugs are only fixed in the next release, the comments usually contain workarounds to avoid getting a cold.

On a different matter I’ve added another bean related method and also some new unit tests for bean handling.

The new method is called getBean($definition). It’s only a few lines of code, but allows to do something like this:

$obj = ZMBeanUtils::getBean('ZMObject#foo=bar&x=y');

After that, you’ll have an instance of ZMObject in $obj with the methods setFoo('bar'); and setX('y'); called.

First place where this is going to be used is as syntax tfor config options. Plugins will be able to specify widget classes and multiple properties to render the form elements of their configuration options.

Perhaps it will even be possible to extend the simple syntax [classname]#[property1=value1&proerty2value2&...] to reference existing objects?

Next on the list is to add support for this to the url mappings. That will allow to specify both controller and view properties without the need for more parameter (instead there will be less!)

I just noticed that google results now show sitelinks for zenmagick.org. Yay!

a) Class preloading vs. loading on demand

The class loader in ZenMagick is responsible for resolving class names a runtime. Obviously, this works only by using ZMLoader::make(..) rather than the PHP keyword new.

Now, one of the conventions in ZenMagick is that files that contain a class start with an upper case letter. This corresponds with the convention that class names start with an upper case letter [and that file and class name must match].

Filenames starting with a lower case letter are assumed to contain static code [functions, defines, etc.) and are loaded immediately when found.[There is one exception, of course, being that in the case of a theme's extra folder, local.php is guaranteed to be the first file to be loaded.]

So, class preloading is easily done by putting the class in question into a filename with a lower case filename. Then, it’s also perfectly safe to use new to create new instances of that class.

The downside is that code is loaded whether it is needed or not. Using ZMLoader::make(..), classeswill only ever be loaded if they are actually required.

b) Database transactions

As of 0.9.42. it is possible to enable transaction support in controller code. That means that allo database activity inside a controller [processGet() and processPOST()] is executed in a single database transaction. Obbviously, this requires a database that supports this.

To enable transactional support the setting ‘isEnableTransactions‘ needs to be set to true.

Last week I was asked if it would be possible to use the CSS click-show-hide menu mod in ZenMagick. After some quick testing it turned out that only some minor changes are required in order to get it working.

Of course, there are some things that could be nicer. With product counts enabled the generated category tree uses an additionl 260 database queries (even thought that is not really news).

I changed the mod to using the ZenMagick API which kind of fixed that problem. One minor issue remained, though. The original Zen Cart code calcualtes the product count on a category sub-tree, not just the actual category. So the numbers are not quite the same. I might fix this, even though I doubt that this is a major showstopper.

The really interesting question now is how to wrap up the resulting files. All there is are the original javaSript, CSS and image files (CSS image path adjused to suit the ZenMagick file structure), the class that generates the HTML and the sidebox template file.

(more…)