With the MVC code now finally in shape to handle something like the new ZenMagick admin application I wonder if it is time to split of the MVC code into its own project.

I know this would mean more admin work, etc. but I also think there would be some serious advantages:

• People could use and test the code independently from ZenMagick
• Things would be easier to document

In particular the second point is something I am interested in. Documenting ZenMagick is hard – there is so much stuff all over the place. To be able to step back a bit and concentrate on the underlying architecture without the relevance for a particular application (store/admin) would make things a lot easier, IMHO.

On the other hand, reading the MVC docs would be of immense value to people trying to understand how ZenMagick works.

Perhaps a first step could be to create a separate area in the wiki to start documenting the generic MVC code. Something that would have to be done anyway and to be honest I’d rather do that than documenting the store itself…

Also, I guess a separate release package would be a good idea. That way it can be used separately and hopefully a lot more testing is done.

The good think about the splitting up I’ve done over the last few releases is that now it it a lot easier to identify new features the MVC code needs in order to help make the store/admin development easier. That way the application development is driving new features in the base code and sometimes this also results in refactoring to make the base code simpler.

Today I reached a milestone in my pursuit of trying to make the ZenMagick MVC code more generic. The ultimate aim is to be able to use it as generic framework for any PHP web application.

With the last check-in, just  a few minutes ago, it is now possible to browse to this URL inside the zenmagick folder: zenmagick/apps/sample/web/index.php and see the text ‘Hello world!‘

Actually, you’ll see the line twice. This is due to some incompatibilities between the file layout of the sample app and the current storefront code. Eventually this should be fixed by moving the storefront code around one more time!

However, that is not that important. The good news is that I now can work on the core and mvc packages without any side-effect from storefront code. Also, this exercise allowed me to find and fix quite a few more dependencies on storefront code that still existed in core and mvc.

I’ve been working on yet more cleanup of the startup and init code to move closer to a framework that is generic enough to be used as general PHP framework.

While this is not a top priority, it’s something I enjoy and that also add value to ZenMagick (well, most of the time).

The improvements to the loader have also helped reducing the code in the main init.php file. Although the code got removed from there doesn’t mean that it completely disappeared, though. A lot of it ended up in ZMEventFixes, which now is more of a shopping cart init class rather than just a bunch of things to run in order to make zen cart happy.

The more time I spend on all this there more it feels like each theme is, in fact, a separate application. The only important difference, however, is that they can (and do) depend on each other. Ignoring that for a moment, what do we then have left?A number of themes,  one active at a time (unless using the multi site plugin to allow different domains to point to different themes).

I wonder if eventually it might become feasable to have the webserver’s document root point to a theme folder and really treat each theme as a separate application using the ‘ZenMagick framework‘.

Obviously, the name theme would then not be appropriate any more. Still, all of that is far in the future. One thing is nagging at me, though and that are the theme info classes. Currently, they do not add a lot to the overal architecture. Also, except for the layout settings (specifying that default_layout.php is the default layout file, for example) there isn’t really a lot in there that is still used I’ll have a good think about removing some of it.
In particular the code related to JavaScript does seem a bit old fashioned and with jquery and Co. around, there isn’t much point in configuring JS for each page any more.

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…

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.

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…

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