Renamed the main zenmagick folder and both the new admin UI and the MVC sample app still work

With the ongoing progress in the new admin UI I’d like to step back for a moment and review the current template organization.

So far, the templates use a similar approach as the storefront code. Meaning there is a central layout file that controls the overall page structure. The actual variable page content is rendered by an individual view template for each request.

There are some obvious advantages in this system:

• Central layout
  Changes to the general page structure are done in a single place
• Simple views
  All a view has to do is to create HTML for a rectangular box – the view. That content then gets stuffed into the right place by the layout template – done.

However, there are also downsides:

• No control over anything outside the actual view
  Beside the actual view contents there are a number of other elements on a HTML page that are also request specific. Typical examples are: page title, meta tags, crumbtrail, custom CSS and JavaScript.

I am sure there are more, but the above is what I’d like to look at in this post. While there are reasonably well working tools to handle custom CSS and JavaScript, there isn’t really a great solution for some of the other elements.
Of course, I could write even more tools classes to manage each and every element outside the view, although that looks like a lost case as there will always be new things to consider.

So, what’s the alternative?

The other extreme, of course, would be to code the full page structure on each view (and drop the layout, which can be done). It is hopefully clear that this can’t be the answer. I still have to see a project where this approach, over time, hasn’t lead to diverging page layouts between pages.

So, the question is: is there a middle way?

One thing that would become clear quite easily when trying to code each page in full is that common elements would be extracted and stored in separate template files for all to (re-)use. An technical alternative would be to wrap common content in functions (or macros, depending on the template engine).
This would allow each page access to all relevant page elements while minimizing the duplication of code/markup [basically reduced to html, header and body tags).

Perhaps something worth experimenting with before committing any further to the current system. I am willing to spend some time to investigate this in practice before the work involved to change all templates becomes too big.

It’s certainly going to be interesting and I will post more about it as I go.

I am at a point in the admin refresh where I would like to integrate existing zencart configuration options (and groups). Pulling that out of the database and displaying the groups and related options is not so hard. However, there is the big question about how to make the stored zen_cfg_xxx functions work.

Since the new admin UI will not include more that the absolutely required zencart config files this is somewhat tricky. So far I have considered the following:

• Custom loader
  A custom class/code loader that would load zencart code on demand. A lot of hardcoding might be required. However, it won’t solve the problem of missing functions.
• Re-impementing required functions
  This would work, although it would be a pain. Hmm…
• Mapping zen_cfg_xxx() methods to ZenMagick widgets.
  I hope this is is going to work as my gut feeling is that it will require the least work and remove any dependencies from the UI itself.

If there are other options please let me know.

Again late – again no real excuse other than my cold maybe.

It’s hard to quantify what I’ve been doing the last 10 days. Mostly refining the dashboard code, I guess. It is now fully functional (except for widget options) and I am quite happy with it. It could perhaps be a little bit snappier, but then that might be a side effect of testing everything in a VM and not enough memory.

Fixed the attribute issue in combination with 1.3.9.x. and a few other small things.
I am stuck with the catalog manager upgrade – I can only take so much new JS at a time… For a change I might actually integrate the jquery accordion. That might be a good solution for the LHS sub navigation. I’ve also some ideas about how plugins are going to register new admin menu items. The main issue looks like finding a way to specify the path (main nav [ie Tools, Plugins, etc] and then the accordion main item and the actual title and URL). That will be needed somehow in order to flag the active menu item.

Also, I’d like to make things as easy as possible for plugins, so just a single call to register a new item, even if that means creating a new top level accordion item on the given page.

The new dashboad is coming nicely and actually is much fun. It’s derived from jquerys portlet demo (which shows!), however I’ve already added quite a few things.

Except for the styling the UI is pretty much finished with the exception of:

• UI to configure the dashboad (columns, what else??)
• UI to handle dashboard widget options
• persistence of dashboad and widgets

Another week flying by… According to the changelog not much has changed, but that is not the whole truth. At least as far as changed files are concerned this was a most sucessful week! I’ve updated all of ZenMagick to using the new locale l10n functions. Luckily a lot of that was scriptable, but all cases involving parameters had to be done by hand…

Apart from that most of the things happening have been already documented in the previous mini-update.

There are two more things worth mentioning, though.

Firstly, I fixed a long standing (although unknown) bug that prevents product view count updates. So if you’ve ever wondered about that – this is why :<

The other thing is an issue around products with attributes on 1.3.9.x. Not sure why, but if you have a product with attributes in the cart and try to check out you either get a timeout (the default 30sec.) or out of memory – whichever happens to be first.
I haven’t managed to figure out what is going on, though. Once that is fixed I’ll do another snapshot and move back to the admin UI.

As far as the 0.9.10 release is concerned, I’ve just moved all things open from the 0.9.9 roadmap to 0.9.10. Not sure how much I’ll actually manage to do, but at least things are not forgotten. Currently the plan is to finish the new admin code up to a point where it provides at least as much functionality as the current code. At that point I think the next release will be ready. It is perhaps one of the biggest changes ever, although templates are luckily not that much affected. Yay!

Despite my cold I managed to get some work done on the new admin UI and other bits & pieces:

• upgraded xinha to 0.96.1 – the version that includes the fix for the XSS bug
• changed all zm_l10n code to using the new locale service. That means it is now possible to change the locale implementation (from whatever is there now to pomo or something completely different). I actually changed the current l10n.php files to l10n.yaml as that is a lot simpler to handle.
  The ZMLocale implementation in the shared code folder now manages it’s own translation table and behaves the same as the corresponding zm_l10n code before. Actually, zm_l10n and zm_l10n_get now use the locale to lookup the code rather than doing that directly.
• Implemented a new controller for the language tool. The logic moved int ZMLocaleUtils and easily allowed to also add an option to scan the shared folder for l10n string. (It will find all strings wrapped in zm_l10n_get, zm_l10n, _zmn, _zm and _vzm [the last three are the new l10n functions to be used and support gettext style parameter])
• Fixed a really old bug that breaks the product notification form – this must have been there for ages!
• The usual share of not really tracked changes like phpdoc, etc.

• The ZenMagick auto loader only loads classes when used. Its something that can’t be done with functions, therefore it allows to lazy load files as they are needed.
  Of course, nothing comes without a cost and in this case it is the initial scan of the folders to be handled by the loader. However, hopefully I’ll get around to adding some sort of cache to that so things will be a bit faster.
• Using ZenMagick MVC is fun
• The new admin’s lib folder is growing. Current count is 53 files vs. 63 in store…

I think it might be a good time to write a bit more about the new admin UI we are working on right now.

This is not just a facelift for the existing zencart admin, but a completely new application. It is using the same code as the ZenMagick storefront does to handle requests and most of the code is shared between admin and storefront.

However, there are a couple important differences.

1. The new admin is not Zen Cart.
   Now, you’d think that is obvious, but there are certain implications. First of all, this means with the exception of the includes/configure.ph and a couple others, no other Zen Cart code will be loaded. It follows that existing Zen Cart admin code will not work [and there won't be any attempts to try this - at least not from me!].
2. The code is not under admin.
   In fact, the new code will be under zenmagick/apps/admin. Right now there are already three different apps: admin, sample, store. The names are perhaps not that great, but they do work.
   Now, store does contain storefront only stuff, while admin contains admin only stuff. [sample is, as you might have guessed, a sample app and not included in release/snapshot builds]
   The biggest chunk of code will be in zenmagick/shared and contain all the code used by both admin and storefront.

One of the interesting aspects of this breakup into separate apps (while sharing code and avoiding code duplication) is that the folder names are pretty variable.
Changing the admin folder name does work without any other changes (unless you move it up/down in the file hierarchy, of course!).
Another aspect to this is that it is possible to point an entirely different domain name to the admin folder directly. (If done for security reasons, it should be accompanied by some .htaccess rules that forbid all access from the main store domain, though).

So, the way I see it the new and old admin will have to coexist for quite a while. Although a lot of the existing admin pages can be re-done relatively easy, there should be given time to get them right. Also, you can expect a certain amount of Ajax to make things fast and slick.

I have done some searching online, but despite multiple tries I can’t find a decent SQL (MySQL) parser in PHP. If anyone knows one I’d love to hear about that…