About two years ago I wrote a post Is ZenMagick for you? This post is an updated version which is supposed to put things into perspectice, in particular the current status and future plans.

History

ZenMagick started when someone asked me to help setting up an online shop. From some initial code to access the database the code quickly grew to something that started to look like an object oriented API to access the zen cart database.

From there is was just another step to add code that handles rendering full pages. The advantage of using the API in the templates did outweight the fact that is was custom code. Once it was in a state where the code was generic enough to be of use by others it got finally released.

Components

On a very high level ZenMagick still consists of the following two major blocks of code:

1. An object oriented API that allows to access most of zen-carts data in an abstract way, so the caller does not need to know anything about the underlying database structure
2. An alternative, MVC style templating/theme system that replaces most of zen-cart’s templating code.

It is important to keep in mind that the theme system is build on top of the API.  So, while it is possible to use the API without the theme code, the reverse is not.

Since the initial version of the MVC framework the code has changed and matured quite dramatically and now there is a range of sub-systems and key features  that complement each other:

• Validation
  Form validation is done by defining rules for each field. Beside some generic rules like ‘required’, ‘minLength’, ‘email’ and similar there are more specialized rules for things like amounts, checks for unique emails and similar. Each rule is implemented as a separate PHP class that is executed on the server side.
  At the same time each rule may generate JavaScript to perform client side validation as well.
  Put together, changing the active validation rules is all required to change a field from mandatory to optional and vice versa.
• Plugins
  Plugins are an integral piece of ZenMagick. A lot of effort has been put into this area to allow plugins to perform a wide range of different things whitout the need to touch any core file.
  Obviously, being object oriented and taking advantage of inheritance helps a lot. One particular aspect is the fact that plugins may modify the final HTML (or other) contents before it is returned to the browser. This allows for things like page caching, injection of Google Analytics code, etc.
• URL mapping
  In zen cart the code to process a request is based on filenames derived from the value of the main_page parameter. Whilest this is the default in ZenMagick too, there are options to change this is desired.
  Furthermore, mappings allow controller to be re-used for different pages and/or customzied at the same time.
  More could be said, but that would be out of the scope of this post.
• Caching
  ZenMagick comes with a number of different cache implementations that come in two major flavours: transient and persistent. The first exists for the duration of a single request, while the latter one may exist until it expires (or the underlying cache system is cleared or becomes invalid).
• ORM style database access
  Over time it became clear that relying on zen cart’s database code was not sufficient. Today, all database access within ZenMagick is handled by implementations of the ZMDatabase interface. Currently there are three implementations; one that internally used zen cart’s $db, one based on creole and one using PDO.
• Authentication (sacs – Simple Access Control System)
  Another component that is based on configurable mappings. Each page (or main_page value) can be assigned a minimum access level of anonymous, guest or registered. The sacs handler then takes care of ensuring that unauthorized requests are redirected to the login page.
  Another side is that the mapper can ensure that HTTPS is used where conigured. Any attempt to try plain HTTP will be redirected to the corresponding HTTPS URL.
  In theory, this means that all URLs in the templates could be HTTP and the mapper would do the rest by redirecting where required (obviously, there would be a performance penalty due to additional redirects).
• Ajax
  ZenMagick has build in Ajax support. The demo store has some examples of what is currently possible. This is one area where still lots of improvements are possible.
• Guest Checkout
  ZenMagick has build in support for guest checkout or checkout without registering. [Thus the three different status types: anonymous, guest, registered]

Benefits

There are a number of benefits in using ZenMagick. For the most part those are:

• Well documented API that avoids a lot of the cut&paste seen in zen cart templates
• Extensible without the need to modify existing files
• Powerful plugin architecture
• Easy upgrades – no zen cart file changes required