March 14, 2009

demo store update

Tags: , , , , , , , , , , , , , ,
Filed under: ZenMagick — DerManoMann @ 11:20 am

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!

March 5, 2009

release preview

Tags: , , , , , , , , , , , , ,
Filed under: ZenMagick — DerManoMann @ 2:05 am

With the number of things on my todo list for the next release shringking fast its time to have a look at what is about to happen in the next ZenMagick release.
I’ve already written about a few things, but I think it is also nice to have it all in one place. (Also, these posts are usually good starting points for writing the release notes!)

So, here’s a list of things to look out for int he next release:

  • Banner Management
    So far, banners where identified by index (integer) and needed a setting each in order to work. As of 0.9.5 this is going to be simplified and there is actually already some documentation about how things are going to work.
  • Database API
    A number of things changed here, in particular the ability to create type mappings on-the-fly and support for array model data in all xxxModel() methods should make life simpler in a few cases
  • define refactoring
    A lot more defines have been converted into consts in the appropriate classes. Defines are fine, however, I feel that consts are a lot more readable and also it’s easier to find where things actually are in the source code.
  • ZMLayout refactoring
    The service class ZMLayout has been renamed ZMTemplateManager in reflect the newly added methods to manage CSS and JavaScript resources. Short story is that it allows to add CSS to a page even after the <head> section has been created by the template.
  • Support for large result lists
    I’ve explained this already, so I’ll just say that the new solution is SQL based and pretty close (at the bottom) to what Zen Cart currently does.
  • Plugins
    As usual there will be new plugins. First, an initial version of a plugin to manage custom ZenMagick settings in the database. It uses some new widgets and I expect that with the number of widgets growing there will be a lot of improvements in the future.
    Secondly, support for phpBB3 at the same level as currently exists for phpBB2.
    There are also improvements and fixes for a number of other plugins that are, of course, listed in the changelog.
  • Open
    A couple things are still open, but should be included, time permitting: a new search page based on the already existing ZMProductFinder class, make all unit tests pass!

February 2, 2009

active events

Tags: , , , , , , , , , , ,
Filed under: ZenMagick — DerManoMann @ 10:21 pm

Thinking about events yesterday made me wonder why there is actually a very specialised method filterResponse() for plugnis. One of the reasons was that I thought it would be nice for regular code to be able to modify the response, too.

One example of why that could be useful is CSS. In contrast to importing JavaScript, CSS needs to be imported/references in the <head> section of a HTML page. That means if the code that generates the HTML needs some special CSS this needs to be handled way in advance of where the code is actually executed.

One idea is to have some sort of resource manager that is able to access the final HTML and inject all the CSS [either explicitely or by linking .css file(s)]. That way the fact that new CSS rules are required would not need to be known in advance.

One obvious use case would be the new widget class, of course!

Looking at the code I remembered the real reason why this is so special: the HTML contents is passed into the method as parameter and the modified contets returned used as parameter for the next plugin, and so on.

Currently, events do not return values. The only parameter is a hash map that may contain any type of data.

So, to cut to the point, I changed the fireEvent() method to optionally handle return codes. The default behaviour is compatible to the current use, however it is possible for event subscriber to return a changed array.
Strictly speaking this is not really necessary as it is possible to modify the parameter array due to the reference handling in PHP5. Still, should special events require a contract where the parameter is not an array things should be ok.

So, as o f the next release [0.9.5] content filtering will be available to every piece of code that whishes to do so.

events

Tags: , , , , , , , , , , , ,
Filed under: ZenMagick — DerManoMann @ 4:34 am

Zen Cart does have an extensive event system. One thing I feel make it not very useful is that most events are specific to a particular page. For example there is a different NOTIFY_HEADER_START_XXX event for each different page.

In ZenMagick there is the generic controller_process_start event with the actual controller instance as event parameter. In particular plugins that need to run on each page this needs some additional work. (Not much, but there are worse examples).
So, one other outcome of my work to make plugins work (better) with Zen Cart templates is to convert Zen Cart events into ZenMagick events to tigger the same event callbacks from within a Zen Cart template.

Seeing the events using the page_stats plugin is acutally quite impressive. For example a product details page (demo DVD product) looks something like this in Zen Cart:

page_stats_zc

Compare that with the same page using a ZenMagick theme:

page_stats_zm

Again, both pages where rendered without any sideboxes.

You can spot the artificial ZenMagick events in the Zen Cart event list as the keys are lower case. The differences are even more impressive with products that have lots of attributes.