ZenMagick comes with a basic set of Ajax support and tools. This includes both storefront and admin.
Here is a quick overview about what is currently possible and how it is done.

1) storefront
Ajax requests are handled by controllers, just like any other request. The point is that this allows the same theme specific customization like any other page/request. it also means that security settings, enforcing HTTPS, etc. are all available.

There is a difference, though, in that Ajax controller inherit from a different controller base class ZMAjaxController. To avoid having to write a new controller for each Ajax request things are organized a little different, though. Typically, each Ajax request maps to a single method call on the server side (or at least a single operation). This is reflected in the way controller are organized.

Each controller may have multiple methods to handle different requests. Currently, there are 3 Ajax controller:

• ZMAjaxCatalogController
  This controller handles all catalog related requests, for example lookup products, categories, etc.
• ZMAjaxCountryController
  Responsible to return a list of countries and also states for a given countryId
• ZMAjaxShoppingCartController
  Handles all currently implemented Ajax requests related to the shopping cart.

Consequently, each Ajax URL needs two parts: the controller name and the method to be called. The net component of the toolbox has a helper method to simplify generating those URLs:

$net->ajax('shopping_cart', addProduct');

Obviously, you’d need to add at least a productId to the URL (and optionally the quantity). The demo store includes an Ajax demo page that shows most available features.

2) admin
As with all admin stuff, things are a bit improvised. There is a file zmAjaxHandler.php that acts as central entry point for admin ajax requests. All it does is to find a matching controller for the request and execute that. Again, URLs are created using the toolbox with the same method.

That means all Ajax requests are available to both storefront and admin.

Doing the dishes is a great time for me to ponder various things. Yesterday I had a couple ideas for new plugins. Nothing too exciting, but prbably worth trying…

1. A redirect/forward plugin
   The idea would be to allow to configure mappings via an UI to be able to redirect/forward default pages that are not needed. One thing in Zen Cart and ZenMagick is that even if a page is not linked anywhere it is still possible to get there if you guess the URL. And once you know it’s a Zen Cart store that is easy enough to do.
   The plugin would allow to redirect to other pages (homepage, error page, etc) for any page that is not needed.
2. A generic surcharge order total plugin
   This would be the first plugin to implement module functionality. I do have some ideas about how that could work, but that will need more investigation.
   The plugin would then add an order total with an additional surcharge if specific conditions apply (right now that would be specific payment modules selected and/or specific credit card types [AMEX, MASTER, etc/]).

Any more ideas and suggestions welcome.

I have written bits & pieces about the database layer used in ZenMagick, but not really anything that would show how to use it. So here is a quick overview about what it does and can do, plus a few examples.

The interface

All the ugly details are hidden behind an interface, aptly named ZMDatabase.

There are currently three different implementations (provider) included in ZenMagick:

• ZMZenCartDatabase
  This is a wrapper around Zen Cart’s $db with all the pros and cons. This is currently the default, because it works One confusing thing is that using this implementation gets the database stats mixed up, because any query via the API will also show up in the stats for $db.
• ZMCreoleDatabase
  The second implementation around, based on creole. Unfortunately, the project is currently not being maintained, so in the long run this is not a good option.
• ZMPdoDatabase
  The newest addition and the seemingly the fastest, too! Using PDO to do the lover level database access.

So, what sort of services does the interface offer? Access to the database can be done either via model classes (as in Model-View-Controller), or using straight SQL and either arrays or objects as data container. This is true for both read and write/update operations.

SQL parameter handling / binding

Parameter binding in SQL is done using :name syntax. Example: 'SELECT * FROM products WHERE products_id = :productId'. The parameter productId would then be expected either in an associative array, for example array('productId' => 3); or via an object with a method getProductId().

Type conversion

The binding syntax doesn’t include any type information. Information about types are handled separately by defining mappings. This is an optional step, because if no mapping is provided the API will build a default mapping based on table meta data. All type conversions during binding will then be based on that.

One of the advantages of explicitly specifying mappings (as does ZenMagick for all core code) is that it allows to map database column names to property names of objects (a simple form of an object-relational database).

Mappings are set up per table, however a single query might use mappings of several tables (usually all the tables involved in the SQL).

How to obtain a database instance?

An instance of ZMDatabase can be retreived via ZMRuntime::getDatabase(). In this simple form an instance of the currently configured provider configured to talk to the default Zen Cart database is returned.

If you want to connect to a different database/server, then all details may be specified as parameter for getDatabase() in the form of an associative map.
Example:

$dbconf = array( 'host' => 'localhost', 'database' => 'mydb', 'driver' => 'mysqli');
$database = ZMRuntime::getDatabase($dbconf);


Both the creole and PDO implementations should allow to connect to any supported database type, however that hasn’t been tested widely (The phpBB3 plugin will use whatever driver is configured in phpBB3 and that seems to work fine).

Database Driver

As shown in the example above, it is possible to specify the database driver to be used. Both creole and PDO support a range of different database types. Until such time when Zen Cart supports different database types this is of limited use, though.

Examples

I’ll keep this to a minimun and rather add more to the wiki where formatting is not so much of an issue…

Recently I’ve been asked about one-page-checkout for ZenMagick. It’s an interesting idea and a lot of carts allow it.

The checkout is the most critical part of an e-commerce application and Zen Cart and ZenMagick are no exceptions. That, and compatibility issues, explains perhaps why ZenMagick still uses (and will in the near future) Zen Cart code to handle the checkout.

It might be possible to do a one-page-checkout in a way that would suit ZenMagick, but it would be a lot of work. So, my question today: is there enough demand to spend time investigating this further?

I just released a new minor version – ZenMagick 0.9.5.1. This release contains fixed for three bugs that came up today. Sorry for this – I really could need some help with QA…

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 just updated the demo store with a release candidate version of ZenMagick 0.9.5.

There are some interesting visual and other changes that the demo store illustrates:

• Use of PDO based database API
• New plugin to switch between ZenMagick and Zen Cart template
• Improved event support for Zen Cart templates (that’s what the switch is really for!)
  The extended event support now allows ZenMagick plugins to manipulate the final HTML of Zen Cart templates. That means, all ZenMagick plugins that rely on this mechanism can now be used in Zen Cart templates, too! Obvious examples are the page stats and style switch plugin (even though the style switch doesn’t really work for Zen Cart templates, right now).

One thing that is now good to see is the difference in database queries. Even though the Zen Cart default template and the ZenMagick themes do not display exactly the same data, it’s still impressive to see the difference in queries

I somehow lost my release notes so the public release will have to wait until early next week to give me time to get organized again.

Happy demo’ing!

Somehow I overdid it with adding code to purge old cache entries by adding additional code to the memory cache implementation. Turns out that Cache_Lite doesn’t support any modus parameter for memory caching!

So, if you are left wondering where all the additional SQL queries for attributes are coming from, now you know.
Since I plan on releasing this weekend there is probably not much point in posting a bugfix or similar. Anyway, if you want to fix it yourself, just delete the following line in ZMMemocryCache.php:

$this->cache_->clean($this->group_, 'old');

On a related issue here is a nifty small code snippet that allows to display the top queries for the current request (using ZMCreoleDatabase or the new ZMPdoDatabase). Just paste that into your local.php and you’ll see the most often run queries (usually with different parameters):

class DbStats {
public function onZMFinaliseContents($args=null) {
$stats = ZMRuntime::getDatabase()->getStats();
$map = array();
foreach ($stats['details'] as $details) {
if (!array_key_exists($details['sql'], $map)) {
$map[$details['sql']] = 0;
}
++$map[$details['sql']];
}
foreach ($map as $sql => $count) {
if (6 < $count) {
echo '<strong>'.$count.'</strong> '.$sql."<br>";
}
}
}
}
ZMEvents::instance()->attach(new DbStats());

(Reminds me that I am still looking for a good WP plugin to preserve formatting and perhaps even do sytax highlighting!)

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.