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 13, 2009

controller properties

Tags: , , , , , , , , , ,
Filed under: ZenMagick — DerManoMann @ 12:58 am

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

February 2, 2009

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.

January 30, 2009

no themes patch!

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

I’ve spend some time today playing around with the isEnableZMThemes setting and the consequences.

The main issue so far is that even though Zen Cart templates work fine now, quite a few plugins are useless, because they manipulate the final HTML via the call to ZMPlugins::filterResponse().

To fix this, I created a new file patch today. It’s the first since quite a long time which goes to show that things have been rather stable for a while.

The new patch will modify includes/application_bottom.php and insert a single (rather long) new line. That line contains the full response filtering and event handling code required to make plugins work.

For example, the page_stats plugin is now able to inject the page stats into Zen Cart templates and even page caching does work!

So, from 0.9.5 on it will be possible to cache the  HTML repsonse from a Zen Cart template using any of the available caching implementations (xcache, memcache, file) to speed up page delivery!

This brings us a lot closer to a stripped version of ZenMagick that does not include theme code and only supports plugins and admin enhancements. I wonder if that would be good to go back to the zen-cart site as add-on…

January 23, 2009

ajax security

Tags: , , , , , , ,
Filed under: ZenMagick — DerManoMann @ 5:04 am

I’ve just checked in a change that allows to configure access and authentication requirements of Ajax calls on method level. That means it is possible to restrict single methods of an Ajax controler to HTTPS, or require to be registered.

The second would then allow to use the sessions account details rather than an accountId from the URL. That way it would be ensured that users can’t access other users data.

January 14, 2009

random facts XXII

Tags: , , , , , , , , , , ,
Filed under: ZenMagick — DerManoMann @ 9:58 pm

1. Dynamic CSS

Yesterday the question popped up whether it is possible to access the ZenMagick API from within a CSS / JavaScript file.

This obviously involves a performance penalty. Nevertheless it is possible.
The first step is to rename the file. This is essential, because otherwise your PHP will never be executed. For example, you’d rename your site.css file to site.css.php. The second step is to include the ZenMagick file external.php.
Example: (This examle assumes that your CSS file is located in the theme’s content folder)

<?php include '../../../external.php'; ?>
After that you can start using the ZenMagick API as you would in any other template file.

2. Organizing template files in subfolder

Currently all views with the exception of email and popup templates are stored in  a single folder. With the way URLs are mapped in ZenMagick (ZMUrlMapper) it is easy to change that.

Let’s have a look at how things are done for popups right now (core/settings/url_mapping.php):

$urlMapper->setMapping(null, 'popup_search_help', 'popup_search_help', 'PageView', 'subdir=popup');

The main_page value popu_search_help is mapped to a template (also) named popu_search_help. However, the property subdir is set (on the configured view ZMPageView).This means the view will look for the template file in a subfolder popup. To add to this twist, there is some magic code to trim everyting up to the first ‘_’ in the template name when constructing the final filename. This has historic reasons and is likely to be removed in the future. So, this mapping will resolve to (within the theme folder): content/views/popup/search_help.php.

There is another way of archiving the same that is a bit more sane (and a lot simpler), though:

$urlMapper->setMapping(null, 'popup_search_help', 'popup/search_help');

The template value is considered to be the filename without the set template filename extension. So this second mapping will resolve to the same file as the first, just in a much more elegant way.

Conclusion: To organize your view templates in different folders, all that is requires it to add a relative path to the mapping.
Please note that this would require some more mappings than there exist now. Typically, the main_page value is the template name, so nothing needs to be configured at all.