I’ve started converting all ajax calls to using JSON-RPC as format. As it turned out the format I initially created wasn’t actually that different anyway.

The good thing is that there is now a central method to make rpc calls and that will actually look at the format and decide whether the call was successful or not. So far the call was considered sucessful if the actual request returned good.

This also means it will become easier to actually access and display ajax response messages which should make the UI even nicer.

I’ve had quite a bit of fun with the latest version of jquery and the jquery UI widgets. Slowly things are coming together, so after the fold there is a screenshot of the current state of the improved Plugin Manager.

(more…)

With the number of sites using Ajax growing it might be a good time to review some of the Ajax code in ZenMagick.

In particular I’d like to review the returned JSON structures. Right now, all of the demo code just assumes that the data returned is good, as long as there is a successful response. Obviously, that is not always the case.

So, I think it would be good to have some global structure that allows for things like a overall status flag, 1-n messages, plus the actual data (if any).

I do not know if there are established patterns for things like this, but if so I’d like to hear about those – obviously, all other suggestions are welcome too!

ZenMagick comes with a basic set of Ajax support and tools. This includes both storefront and admin.
Here is a quick overview about what is currently possible and how it is done.

1) storefront
Ajax requests are handled by controllers, just like any other request. The point is that this allows the same theme specific customization like any other page/request. it also means that security settings, enforcing HTTPS, etc. are all available.

There is a difference, though, in that Ajax controller inherit from a different controller base class ZMAjaxController. To avoid having to write a new controller for each Ajax request things are organized a little different, though. Typically, each Ajax request maps to a single method call on the server side (or at least a single operation). This is reflected in the way controller are organized.

Each controller may have multiple methods to handle different requests. Currently, there are 3 Ajax controller:

• ZMAjaxCatalogController
  This controller handles all catalog related requests, for example lookup products, categories, etc.
• ZMAjaxCountryController
  Responsible to return a list of countries and also states for a given countryId
• ZMAjaxShoppingCartController
  Handles all currently implemented Ajax requests related to the shopping cart.

Consequently, each Ajax URL needs two parts: the controller name and the method to be called. The net component of the toolbox has a helper method to simplify generating those URLs:

$net->ajax('shopping_cart', addProduct');

Obviously, you’d need to add at least a productId to the URL (and optionally the quantity). The demo store includes an Ajax demo page that shows most available features.

2) admin
As with all admin stuff, things are a bit improvised. There is a file zmAjaxHandler.php that acts as central entry point for admin ajax requests. All it does is to find a matching controller for the request and execute that. Again, URLs are created using the toolbox with the same method.

That means all Ajax requests are available to both storefront and admin.

Recently I’ve been asked about one-page-checkout for ZenMagick. It’s an interesting idea and a lot of carts allow it.

The checkout is the most critical part of an e-commerce application and Zen Cart and ZenMagick are no exceptions. That, and compatibility issues, explains perhaps why ZenMagick still uses (and will in the near future) Zen Cart code to handle the checkout.

It might be possible to do a one-page-checkout in a way that would suit ZenMagick, but it would be a lot of work. So, my question today: is there enough demand to spend time investigating this further?

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.

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.

As part of my work on the new product picker I’ve upgraded to jquery 1.2.6. So today they release 1.3!

Sounds like a goor release with tons of new stuff. I guess I’ll be upgrading again soon

In a way  this is good, because it means I’ll be reviewing all used JS and try consolidate things a bit. In particular the used plugins should be looked at again. Most use cases are quite simple, so it would make sense to review the available options again and go for the best performing alternative.

Another thing is that I noticed that the catalog manager page doesn’t support injecting header code. This is going to be more important with more plugins coming and each having its own requirements.

In fact, I might change the current system of passing around a ZMPluginPage instance to another service. This would also make it a lot easier to avoid including the same file more than once. It also would mean there is no need to change the admin page .php file for each new plugin that wants to include something different.

Of course, there are also the other usual suspects like IE compatibility. I’ve noticed a few glitches in the category tree and right now, the product picker doesn’t really look that good at all :/

On the plus side, I’ve extracted the javaScript and CSS into separate files, cleaned up the code, wrapped it in it’s own class and generally am finished with the actual UI JS coding.

Next will be a bit more layout and beautification. After that the jquery/plugin review. Suggestions for good and simple widgets are welcome. I’ll be looking at plugins/code for:

• (non-)modal dialogs
• a tree view
• tabs (incl. lazy loading via Ajax)
• a date picker
• other suggestions?

With 0.9.4.1 out of the way I’ll be continuing with some more Ajax related work. Next thing on my list is a nice looking product picker. So far I’ve succeeded in reusing the category tree plus some jquery code to load products for the selected category.

To make things even better I just added pagination support to ZMAjaxCatalogController::getProductsForCategoryIdJSON(), so it will eventually be possible to page through all products of a category using Ajax.

(more…)