For the sake of an exercise I’ve started installing IIS (5.1) and PHP 5.3.2 (fastcgi) to see if ZenMagick, and in particular the MVC code, will run without problems.

So far I’ve done the following (pretty much following these instructions):

1. Installed IIS (on XP Professional – I know it’s old but it works for me…)
2. Downloaded PHP5.3.2 nts VC6 (zip file)
3. Downloaded and installed fastcgi 1.5
4. Failed to be able to configure fastcgi using the scriped approach, so did some bits manually (registering fastcgi as handler for .php)
5. Added a new virtual folder in IIS Admin pointing to my local ZenMagick installation
6. Configure PHP to use a custom logfile to be able to see errors :/
7. Run the Permission Wizard on the created virtual directory (right click -> All Tasks -> Permission Wizard) and configure permissions for a public access website
8. Re-enable Default Documents and add index.php to the list

Right now I am at a point where things start to load, but Savant is unable to find the template file – I guess some of the code in ZMRequest that controls the various paths is not working in IIS, but I’ll have to debug that first.
I’ll update this list once I have found out more…

UPDATE:
So far I’ve found one compatibility issue and one regression! The regression was using ZMLangTools instead of ZMLangUtils, so that was easy to fix. The other issue was that in IIS $_SERVER['REQUEST_URI'] is not what Apache thinks it should be :/

UPDATE2:
I’ve also installed a self signed cert to test SSL. This is pretty simple:

1. Download and install the IIS 6.0 Resource Kit
2. Open the SelfSSL shell and run something like: ‘selfssl.exe /N:CN=ZenMagick /V:365′

UPDATE3:
Next on my list, but not yet done is enabling some sort of URL rewriting to allow to use some of the seo stuff. This mod looks quite promising…

Last night ZenMagick 0.9.5 was finally released! I am quite excited about this particular release, because it includes a couple things that make ZenMagick a lot more attractive to existing Zen Cart installations.

For one thing, there is a new patch that allows plugins to access the final HTML content of Zen Cart templates. This has been around in ZenMagick (for themes) for quite a while and proves to be very powerful.

A lot of the storefront plugins (page stats, page caching, google analytics) depend on this feature and now they can be used with Zen Cart templates too!
If you head over to the demo store you’ll see that the HTML generated by the default Zen Cart template is caches like any other page, following the same rules!

Another quite surprising thing (at least  for me!) is the new PDO based ZMDatabase implementation. It seems to be the fastest implementation so far and the demo store seems to do fine using it, so I might make it the default implementation for the next release.

There are also improvements to existing plugins and, of course, a couple new ones. The most interesting one is probably the phpBB3 plugin. It provides the same features as Zen Cart’s phpBB support, just for phpBB3.

I also really like the new theme toggle plugin that allows to switch between Zen Cart and ZenMagick. Probably not very useful for a production environment, but good to compare features, displayed values, etc.

Of course, this is not the end, and I’ve already started working on the next version. In that context a reminder that with 0.9.6 I’ll be removing a lot of the deprecated stuff. Also, the deprecated API support will be removed before a 1.0.0 release, but most likely not before 0.9.8.

I’ve checked in some changes that affect most model classes (and a few others) in that they now extend ZMObject rather than ZMModel to simplify the overall class hierarchy.

In fact, there are a couple more reasons, mostly that I want to get rid of that class completely Initialy, the idea was to collect mode related code in ZMModel. In reality there are exactly two methods left (after the rest moved to ZMObject).

And those two methods are concerned with populating an instance from the current request. With the planned changes around using separate form objects (or just ZMObject instances) and changing the form field names to match the model class properties, those two methods will hopefully be obsolete before too long.

A while ago I wrote that I’ve been working on (yet) another implementation of the ZenMagick database API using PDO.

After some back and forth (the code was removed and readded yesterday) I’ve started working on that again. There are a couple good reasons for that.

Firstly, since Creole is not supported any more, having another implementation seems like a good idea. Secondly, it appears that it is quite a bit faster than Creole (and perhaps even Zen Cart’s $db).

I haven’t had a chance to verify this usingpages with lots of database access, since there are still bits missing in the implementation. The good news is, though, that the tests for ZMDatabase have been improved and extended in the process of filling the gaps.

In related news, I’ve decided (more or less) to make another change to the database API. This will only happen after 0.9.5 is released, though. The methods to control transactions are a bit clumsy and I hope that things will be a bit more intuitive in the future.

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…

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.

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) 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.