Not sure what or when this changed, but there is now an error message at the bottom of my dev ZenMagick site:

‘Fatal error: Exception thrown without a stack frame in Unknown on line 0′

It seems to happen within the exit statement, so after some research I think it is related to error handler or shutdown handler code. Hmmm….

EDIT: Turns out that it is a bad idea to call parent::__destruct(); if that method doesn’t exist…

One of the things on my todo list for ZenMagick is to review the different types of config/option/setting formats used. Right now there are:

• plain PHP with static code
  This is handled via the loader and the most prominent special cases here are local.php files which are fine, though
• PHP code without the <?phph ?> tags
  Used for the database mappings – this should/could be nicer I guess, in particular since it might get cached as serialized array anyway
• list of method calls in a single global function
  Done for the sacs and url mappings. These could be a single array and perhaps should be. However, it would be nice to have a simple format that can easily be parsed

So, what do I want/need? .ini fileformat is too simple as there is some hierarchical data, although not too deep. Some nesting would be good too.

Of course, XML might be an idea, however I do not have any experience with XML and PHP and do not know what performance is like.

Any ideas?

As mentioned before, I’ve started playing around with Savant3 as an candidate to complement the current view code.

So far I’ve got a simple subclass (plus about 5 lines of patching in Savant.php itself) to make it usable as template wrapper.

I appreciate that it is rather simple and I can’t really follow some of the complaints about code missing compared to Savant2 (which I haven’t looked at at all).

Advantages

• Savant provides pretty much everything the current theme class has to offer. True, it doesn’t have a method to generate theme URLs, but that is easy to add by subclassing. Also, since there is a setting to configure the default view class it would be easy to switch between implementations.
• Another feature of Savant (as of version 3) is support for compiler. The default templating system (if you want) in Savant is straight PHP, sprinkled with some nice helper methods.
• However, there is support for compiler. Another word to describe this might be pre-processor. So, how is that good? Well, I guess it could be used to implement caching on block level. Considering that each sidebox is included separately, some could be cached, even if the page as a whole is not. I think Smarty does a similar thing, even though this migh be abusing the system a bit…
• I’ve mentioned that templating is just plain PHP. This would tie in with the current ZenMagick approach and could  could be implemented almost transparently.
• Another nice thing is that theme inheritance is pretty much build in. Savant allows to configure as many search locations for templates as you want. Done in the right order, this behaves exactly like theme inheritance! And with much nicer code!

Beside the goodies above using Savant might have some positive side-effects on other ZenMagick code as well. For one thing, it would force me to really continue with my theme code cleanup. It might be a good time to get rid of the them info class altogether, perhaps in favour of a simple properties file?

So, I am really tempted. However, there will be more experimenting before I’ll be  making a decision. Until then there is more code cleanup to be done. On the other hand I might put this into the mix while I am at it … stay tuned

I was recently asked if I’d be interested in reviewing a book about Zen Cart. Since I’ve never read a book about it I figured that that could perhaps be an interesting experience [Usually, I prefer to read the source].

The name of the book is Zen Cart: E-commerce Application Development, written by Suhreed Sarkar. It’s available from the original publishers site at Packt Publishing and also from the other usual suspects.

The book is mostly aimed at people considering starting an online business but also developers and existing Zen Cart users that want to improve their business. For my taste some of the book (in particular the introduction) are a bit to long winded for more experienced readers, but I guess that can be said of a lot of books.
Still, it will give beginners a good idea about what Zen Cart (and e-commerce) is about. Since there are so many different aspects to Zen Cart [and therefore this book] I’ll follow the book’s structure to organize the review, so here goes… (more…)

There is a reason that it has been quiet for a while around ZenMagick. I’ve got a new project:) Nothing too serious and most likely not even a real project.
I’ve tried adding some new features to PHPDoctor, the PHP documentation creator that I use to generate the ZenMagick API documentation. Since it turned out to be a lot messier and complex than expected (perhaps due to my inability to understand the code, I might add) I started re-implementing everything (but not from scratch).

(more…)

I just checked in a fancy change to ZMObject that allows to dynamically add methods to any class (assuming the class extends from ZMObject) at runtime.

So, what’s the deal? you ask? Well, I always have been slightly uncomfortable about the fact that if multiple plugins wanted to extend/modify an existing core class, say, for example, ZMProduct, there could be only a single winner.

The alternative is to add new services and use them in templates. Of course, that is ok and all, but wouldn’t it be much cooler to just use the affected class directly without something like the following?

$value = MyService ::instance()->getFoo($product);


So, compare that with:

$value = $product->getFoo();

And here is how this can be done:

class MyService {
/**
* @param mixed target The instance the method was invoked on (instance of ZMProduct).
* @param var ... some Some single parameter.
*/
public function getFoo($target, $some) {
return "foo: ".$some.": ".$target->getName();
}
}

ZMObject::attachMethod(‘getFoo’, ‘ZMProduct’, array(new MyService (), ‘getFoo’));
$product = ZMProducts::instance()->getProductForId(3);
echo $product->getFoo(‘xx’);

So, what does it do?

• First there is a new class that implements the calculation of the new property.
• Next we attach an instance of MyService as handler of getFoo calls on ZMProduct objects
• Load a product from the database
• call getFoo('xx') on $product

The same works if the handler is a simple function:

ZMObject::attachMethod('getFoo', 'ZMProduct', create_function('$target, $some', 'return "foo: ".$some.': '.$target->getName();'));

Another of those things that are not strictly necessary, but nice to look at

Yesterday I checked the creole homepage for updates and to my horror I discovered that the project is being abandoned.

While I can understand the reasons behind this step to a degree, I still feel sad on different levels. I’ve picked creole as alternative to the current Zen Cart database code as it seemed mature and, at least to me, rather promising.

Also, the style it is coded in is very close to my ideas about how PHP code should look like. Seeing that the repository is going to exist, maybe there is still hope that someone else will pick up the project.

For ZenMagick, nothing really is going to change. I’ll be trying to convert the current 1.2 beta code into a single file as I’ve done with the 1.1.0 release (I had a go at that in some spare minutes, but there have been changes that make the current import code break, so it’ll take some time).

I am glad that I took the time to write my own (thin) database layer for ZenMagick to avoid depending on a single external project. This is proof that it was time well spend, even though the circumstances are very unfortunate.

I might evaluate another database API for the future, although this is very low priority and will be far in the future. Suggestions are, of course, welcome.

I’ve been playing around with implementing new ZMCache provider. xcache is nice and easy to test, in particular since it comes with a simple admin interface to dump the cache entries.

I just found something similar for memcache and it was really a big help.

Besides being able to verify that adding/removing from memcache worked, it helped figuring out how to retreive the stored items and, more importantly, the cache keys.
Since ZMCache supports grouping of entries the only way to handling this is to iterate over all entries and compare prefixes.

Initially I implemented some internal tracking. However, I wasn’t sure whether that would stay in sync over time. Iterating over entries might not be the most performant operation, but considering that this is ever going to happen from within the admin interface of ZenMagick this should be fine.

I’ve finally had the time to download and install ZendOptimizer and ZendGuard.

Both seem to work fine with ZenMagick and in particular in combination with core.php help speeding things up a lot.

I haven’t got any numbers to compare, but relative to running the store without any optimisation make up for perhaps 40% performance gain.

So, this might be time well spend invetigating PHP acceleration, unless your hosting provider does that already for you.

I just checked in a couple changes that fire new events in case of a new account being created. The really nice things is now that event listener have a chance of modifying the account directly without having to change a single line of core code (or globals!).

For example, the following code would change the default authentication status for all new accounts:

class Blocker {
public function onZMCreateAccount($args) {
$account = $args['account'];
$account->setAuthorization(ZM_ACCOUNT_AUTHORIZATION_BLOCKED);
}
}

ZMEvents::instance()->attach(new Blocker());

I guess it couldn’t be any easier than that (other than re-defining the default authentication value