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!
Comments Off
A couple more bugs have been found which must have been around for a while, actually. Not sure why noone picked those up or reported them, though.
Anyway, just a friendly reminder that it pays off to keep an eye on the bug tracker. Even if bugs are only fixed in the next release, the comments usually contain workarounds to avoid getting a cold.
On a different matter I’ve added another bean related method and also some new unit tests for bean handling.
The new method is called getBean($definition). It’s only a few lines of code, but allows to do something like this:
$obj = ZMBeanUtils::getBean('ZMObject#foo=bar&x=y');
After that, you’ll have an instance of ZMObject in $obj with the methods setFoo('bar'); and setX('y'); called.
First place where this is going to be used is as syntax tfor config options. Plugins will be able to specify widget classes and multiple properties to render the form elements of their configuration options.
Perhaps it will even be possible to extend the simple syntax [classname]#[property1=value1&proerty2value2&...] to reference existing objects?
Next on the list is to add support for this to the url mappings. That will allow to specify both controller and view properties without the need for more parameter (instead there will be less!)
Comments Off
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.
Comments Off
I’ve filed two new bugs for 0.9.3 which are also still in 0.9.4. Doesn’t shed a good light on my testing, but there are simple workarounds for both.
I just wished someone would have told me before – I am sure there must have been people struggling with this. Sigh.
Comments Off
