Visions

From ZenMagick Wiki

Contents 1 What does this mean? 2 Topics 2.1 Framework 2.2 Store stuff 2.3 Admin 2.4 Themes 2.5 Plugins 2.6 Misc

What does this mean?

Visions is perhaps not the best title, but I couldn't come up with a better one, so for now this will have to do.

There are lots of features in ZenMagick that suddenly popped up. Some are the result of immediate need for functionality, others are things I've been thinking about for some time and then, suddenly there are a couple hours and a few good lines of code to start and then they are there. I've got quite a few more ideas about what could be done with ZenMagick and I think it is time to write them down. Some I do remember all the time, some I lose and find again. Definitely time to start writing things down!

So, this page is going to replace my tasklist for 1.0 blog post.

I've also added the stuff from small, unmaintained todo list that came with the previous releases, so that will go.

Topics

Framework

• Extract the generic framework code (MVC, validation, database API, and perhaps a couple more) into separate sub projects (would allow to reuse the code for a new admin app);first second iteration complete
• Review/rewrite the result list stuff to be able to handle really large results
• Add delete and create to more services
• Review different types of config/options files used (.php, .txt, functions), agree to a some sort of standard and convert code that doesn't match that standard (yaml)
• More widgets (product picker, see below), everything that exists as zen_cfg_xxx() function and more
• Zen Cart module proxy classes that would implement some ZM specific shipping / payment / ot interface to allow Zen Cart modules to work
• Further improve the database API; some things are not consistent, some not practical and some are still missing (aiming for using the PDO based implementation as default things are starting to look really good)
• Get the file permission code working
• Review model classes and perhaps think about form data classes to separate those two (this could definitely improve the date handling code)
• review and sanitise the date handling code ;)
• have some sort of resource manager that can be used to add JavaScript or CSS to the current page even after HTML generation has been started; could have methods for addHeader, addFooter (typically before closing body tag) and either for formatted contents or link, script, etc. methods with attribute map
• use DIRECTORY_SEPARATOR rather than '/' everywhere; done in all significant places, not sure if patches really need it, though
• Extend ZMSacsMapper to support group based access control To a degree this is done as the new ZMSacsManager allows to delegate to multiple handler
• Decouple SacsMapper from Accounts and have a credentials class instead (and a wrapper implementation around ZMAccoount)?
• allow multiple SACS restrictions on a resource (url) (registered and guest, etc.)
• Make ZMRequest a proper object again (not a singleton or static methods); although, there are places where access is done via ::instance() rather than via parameter
• Also, make service method parameters like languageId mandatory, so the code gets decoupled from ZMRequest and/or ZMSession
• </strike>move plugin utils into new toolbox class</strike> (deprecated all of them!)
• decide whether to use ZMSettings::get('isAdmin') or ZMRequest::isAdmin() [the second looks better at first glance]
• store settings somewhere (initial work in zm_settings)?
• have separate wrapper around store settings (eg. name, etc)?
• restructure to have zenmagick (and zen-cart?) outside htdocs?
• use reflection to populate model classes from request? (related to renaming form fields to match bean properties) (all done, except for properly flshing out ZMFormBean)
• add a special case to ZMRequest to handle checkbox values by looking for a _[name] value as previous value to decide whether it exists or not (kind of)

Store stuff

• Edit cart attributes
• proper, consistent multi store support (lots of admin and db changes?)
• Add code in ZMCreateAccountController to figure out if an address needs to be created (this will allow to create accounts without address to use as user db for 3rd party apps like forum, etc)
• implement missing weight and onetime prices for attributes
• product_free_shipping_info and a couple more are still missing; generate mappgings for product types dynamically to allow adding new ones without the need to do more configuration work
• file attribute
• add more store specific events like:
  • product changed (availability, etc)
  • plugin changed installed/removed (useful for stuff like cache or core.php that will need a refresh)

Admin

• write another patch to hide admin things that are not relevant when using ZenMagick
• Product picker (work in progress, should hopefully be ready for 0.9.5 or 0.9.6)
• Plugin installation/upgrade UI
• Have a page similar to Catalog Manager for orders/fulfillment
• Create admin toolbox class to avoid mixing things with storefront
• Improve banner management with options to control the pages a banner is allowed on (page name, page group [checkout], categoryId, productId)
• add simple CMS option by replacing special formatted HTML comments with content (plugin?) (blockHandler!)
• new dashboard
• new layout
• rewrite attribute management - Catalog Manager plugin?

Themes

• review l10n, i18n
• move theme template methods to a toolbox class
• make toolbox the template API, so service changes do not affect templates directly (also would make some methods simpler)
• document implicit template vars
• change all form input names to correspond to the data bean property names
• make filter/sorter look nicer and easier to configure (autodetect??)
• make price filter actually work
• generic interface to manage theme settings
• sidebox patches and plugins work relative to the current theme only - should they update all themes?

Plugins

• product associations; framework and basic handler will be in 0.9.7
• Facets (there is a plugin in SVN, but that's more a prototype and not complete)
• Rule based promotions
• Settings (could also be core, but I'll be starting this way - it's actually a lot nicer to do that way as it keeps things separate) needs improvements, though
• Move all unit tests to a separate plugin and add all plugin tests (at least for centrally hosted plugins?)
• Improve the features plugin as discussed elsewhere (there are some emails I wrote about that - drop me a line if you are interested)
• phpBB3 support - this seems to be a favorite on the blog
• Product bundles
• Improve the wordpress plugin, add support for user sync similar to what the Zen Cart mod does
• newsletter subscription
• order total plugin 'surcharge' if conditions apply
• redirect/forward plugin

Misc

• Get some alternative bootstrap code working (might need some general rewrite of the init plugins, though)
• Move source code to git(hub)?
• Host own forum and bug tracker
• Make languageId parameter mandatory everywhere; in fact, this affects a few more parameters; the aim is to make services and otherwise generic code session/request agnostic duplicate
• Remove zm_ prefix from all variables set by the controller ($request, $resultList, $product), etc? (Started)
• Help improve phpdoctor; in particular support for {@inheritDoc}, and something that could be used to document supported class properties when using beans (via __call()). The latter would really help reduce the boilerplate code in model classes and lower the threshold to create new model classes where needed rather than reusing classes
• Finally get a logo and design!
• Write the promised 5 minute installation guide
• Put more stuff on the wiki - although I wish I could get more feedback on what is needed
• Separate installer?
• Build releases that include Zen Cart base?
• Version update check (might need different hosting for release files)
• Write more unit tests, make unit tests required for new code
• fix more code marked TODO or XXX done for the reoganized core and mvc packages
• Restructure project folder hierarchy to move non content and config files out of docroot
• get rid of wrapped zen-cart data (like orders, shopping cart, etc)
• in cases where settings apply to singletons but also to individual instances (for example custom ZMDatabase instances), allow to override global settings; instances could use settings as defaults for regular properties, so they can be changed like any other setting