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.

February 1, 2009

reducing price related database queries

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

One of the new features in the upcoming Zen Cart 2.0 version is going to be a reduced number of database queries for price lookup. Most of those queries are attribute related and therefore do not affect all stores/products.

Due to the current work on making ZenMagick properly available for Zen Cart templates, I’ve had the chance to do some easy comparisons. (more…)

January 30, 2009

widgets

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

In my last post I mentioned widgets. Today I’d like to write a bit more about what they will be in the context of ZenMagick.

Without beeing to much affected by other applications use of widgets (I’ve never used a WordPress widget, for example), my idea of a widget is that of a self contained piece UI and code. (more…)

January 29, 2009

plugin news

Tags: , , , , , , , , ,
Filed under: ZenMagick — DerManoMann @ 1:15 am

I figured it is time to write an update on plugin development. Since most work these days is on plugins (and the corresponding changes to core to make them work, of course!), that’s where most of my spare time goes.

A number of different things are happening at the same time, thus slowing things down a bit..

  • Product associations
    I haven’t made much progress here. My initial investigaion into jquery 1.3 was not very successful – I guess it will need some more time for plugin coders to catch up with the new version.
    Only progress is that there is now an Ajax controller that allows to lookup existing associations. Next step will be to implement creating/updating associations and then I should be able to finally work on the general UI and hook it all up.
  • Settings
    After an email conversation with one of our clients I have started working on a settings plugin. The plan is to have a nice UI to create new settings rather than editing the global local.php file.
    Of course, this did not go without creating some unexpected work! To make things look nice and customizable, I’ve started working on something that has been on my list for a while: widgets.
    Widgets are an object oriented version of Zen Cart’s zen_cfg_xxxx() functions [for example: zen_cfg_select_drop_down()]. The advantage of using classes is that it is possible to:

    • customize the UI
      This is possibly not that important, but just fun to have. For example, I’ve created a boolean form widget that can either render as radio button group or select/dropdown.
    • Each widget can have different parameter
      Since widgets are configured as bean using a GET parameter style (name=deng&foo=bar), it’s easy to implement and configure custom properties for each widget
  • Subscriptions
    One of my clients is very close to moving a new plugin to production that allows customers to subscribe to orders. This means they can select from a range of schedules (weekly, monthly, etc.) and new orders will be generated automatically.
    The only manual step is that payments are not integrated. The current payment API is tricky at best and messing even more was nothing I fancied. If the plugin proves useful it might be something for the future.
    At this stage I’ll hold off releasing this to the public until we’ve got some live data to see how well this is working.

January 19, 2009

product associations

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

Since it is now possible to inject methods into ZMObject based classes, I figured I might as well use it. In fact, this is how most new (framework) features come to exist.

So, what better place than to keep improving the unfinished product associations plugin. I decided to attach a new JSON/Ajax method to the catalog ajax controller. Of course, the devil is in the details and I soon found myself fixing some obscure things in ZMBeanUtil and the reflection code in ZMAjaxController to allow it to find injected methods :}

Once that was all sorted I really could use the existing catalog controller to access my new method :) ! The nice thing is that I do not have to inherit, but due to the fact that the injected method always has access to the original target object, it’s easy to access all relevant data/methods of  the original controller.

And, because it is so nice, another screenshot of the current state of the product picker. The image shows the picker on the second page of products of the ‘Big Linked’ category with one product selected in the current list and one from another category.

product-picker3

January 16, 2009

method injection

Tags: , , , , , , , ,
Filed under: PHP,ZenMagick — DerManoMann @ 12:11 am

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

« Previous Page