Dev:storefront-admin code sharing

From ZenMagick Wiki

Jump to: navigation, search

Contents

Introduction

In order to get the admin pages to the next level and use the ZenMagick MVC framework as intended, there are a few things to consider regarding sharing of code. Also, there is still an open question about whether storefront and admin need to be part of a single app. In some ways splitting it would make things a bit easier, but since most of the code should be shared there is also reason to keep things together. This document is an attempt to collect all areas of code/configuration where sharing might be a problem.

Logic Overlap

One of the main issues is that while it is easy enough to give admin pages some separate code via unique toolbox tools, there are instances where things are not that easy. Perhaps the best example are emails generated via the admin UI.

While the admin UI (form to collect customer details, etc.) needs to use admin specific code, the email view that renders the email content needs to run in storefront context. This means, for example, URLs generated within the email context need to point to the storefront rather than admin pages, etc.

Assumptions

  • This issue is only related to email, there will never be need to re-use a storefront view in admin
  • email templates should not use $request

Issues

  • Toolbox
    Separate toolbox ($admin) for admin pages
  • MVC code
    ZMRedirecView uses the toolbox to create the redirect URL
  • ZMTemplateManager
    Using this will create storefront URLs for .js/.css
  • Controller
    admin/index.php?main_page=login currently results in a redirect as the storefront login controller kicks in. At the same time URL mappings are probably needed to generate valid URLs for emails
  • ideally, for admin we'd like to use just the MVC code with bits of glue - that means using ZMSession rather the storefront's Session class!

Ideas

  • Split init.php into two separate files: one for storefront and one for admin
  • split all application code into store | shared | admin
  • Share url/sacs mappings in a single file - this would mean that the admin login would need to be renamed!?
  • Have admin controller added *after* storefront stuff?
  • controller suffix: make configurable and use AdminController for admin requests?

Plan

  • Have individual init.php scripts (or code in init_templates.php override) for both admin and store to set things accordingly
  • Move all admin code (except the required zc overrides [boxes, etc.]) to zenmagick/apps/admin
  • Add support for shared code in bootstrap
  • move store to zenmagick/apps/store
  • Split code into store / shared / admin; Most code will be shared, except:
    • store/lib/mvc, except for generic Ajax controller (checkout/cart are store only)
    • current admin Toolbox tool
    • some of the admin utils - some is needed, though, for example the menu stuff is currently referenced in sf too!
    •  ??
  • Have separate url/sacs mappings and also separate config - defaults have to be shared, somehow, with some overrides in admin

This list of actions will make both admin and store proper apps in the sense of a ZenMagick web app [except for themes]. With plugins and themes staying put, there won't be any visible user facing changes (ie. urls to images and other resources stay the same).

TODO

  • convert wysiwyg editor selection to user pref
  • add single wysiwyg plugin to release? which one?
  • ezpages overview still using old ajax code
  • no wysiwyg option ezpages
  • wysiwyg editor not active static pages
  • investigate phar archives to pack lib / shared / etc
  • need setting to explicitly enable zc MVC request processing for given request ids
  • grid options in the dashboard config popup
  • change image color of wrench or add circle
  • add code to update the title of admin pages
  • cleanup languageId defaults in API - this doesn't work with a default ZMRequest class (might require to extract some code from apps/store/lib/mvc/Request.php into a shared utility class
  • move away from using the big defines in PLugins.php - right now it is impossible to uninstall/install within the same request as the values can't be changed (again!)
  • upgrade included jquery + plugins:
    • some plugin to allow to sort table rows - sortable!!
  • centralize language id handling and session defaults in general (login controller)
  • make clear distinction between admin UI language and selected language for things like static pages, ezpages, etc.
    If nothing selected, default to admin UI language - assuming that store and admin languages generally should be the same - or use default language?
  • re-implement display of category products in tab as alternative to products in the tree - important for large databases!
  • create new admin menu wrapper classes that allow to insert before/after id, etc not required any more
  • create catalog manager plugin subclass
  • get MinMax validation rule working for both min and max - needs updated/changed JS in validation.js
  • change current way of syncing data via the view for email context updates to using a simple ZMObject instance
  • ajax handler to set the wysiwyg editor to allow to have a jquery modal/non modal dialog setting the editor..
  • generic admin user preferences handler - generalize dashboard conroller
  • minify breaks admin (looks like a jquery issue, for example: http://dev.jqueryui.com/ticket/5576)
  • add default language (for content editing), wysiwyg editor and such to preferences page (db?)
  • make sure db mappings stay in sync - perhaps remove from admin and copy as part of the build?
  • dashboard widget options handling
  • create new event listener that allows to change/set meta data and can be called from templates (in particular views!); this could replace the existing metadata toolbox tool and (using similar code) the crumbtrail code (which would remove that logic from controllers where it doesn't belong at all)
  • finish updating packages
  • extend reorganization of js code - validation should be module? of the main zenmagick var
  • add all generic js l10n strings to zenmagick - perhaps zenmagick.l10n.xxx?
  • find a place in apps/example|admin where pomo files are located and then integrate pomo into core
  • use (and handle in client code) the new ajax response strucures
  • settings: allow to set a group for a new setting!
  • extend ZMViewUtils to not only handle resources but also updating any header element and also adding new stuff??
  • decide what to keep to be able to install properly (centralize installation code)
  • start some proper regression testing
  • redirect view (or forward) for catalog content controller
  • add main readme to make github happy
  • upgrade ajax request/response data to json-rpc 2.0
  • fixate handling of path/url of images from either admin or storefront (DIR_WS_IMAGES, 'apps.store.docRoot', etc)
  • do we need language icons? (fam-fam)
  • check what happens if language set to just something like 'de' instead of 'de_DE'
  • move release notes to wiki

Insert non-formatted text here

DONE

  • db session handler
  • make findView() view data override getViewData() data
  • sacs handler
  • avoid having to subclass zmrequest just for getUser()?
  • persist messages in session for redirects
  • implement followupUrl support when redirecting to login after requesting protected resource
  • implement login/logoff
  • make plugin admin pages work
  • review Runtime::getLanguage()
  • restructure all packages
  • get validation working in mvc
  • upgrade included jquery + plugins
  • fix session/cookie timeout bug in mvc/session handler
  • properly display error page
  • create ajax/json response object that wraps the general response layout and provides stuff like ->addMessage() ->setErrorCode()...
  • get rid of plugin admin controller classes, etc - done, except for catalog manager plugins
  • add locale framework to core
  • implement short tags as filter?
  • ensure there is always one valid role left!
  • look at $request->getUser()->isDemo() and restrict actions accordingly in new controllers
  • allow to configure singletons as beans - set up generic schema to allow to set bean definitions via settings for singletons
  • add support for optional group paramter on plugins page
  • use _vzm() in admin
  • update lang tool to look for _zm, _zmn and _vzm too!
  • fix quick edit plugin (stale data)
  • check wrapper rule validation use - $req changed to $request!
  • add dashboard code (new table to manager user prefs plus controller)
  • add option to scan the plugins folder in l10n tools
  • add option to scan admin, lib/zenmagick/[core/mvc] folder in l10n tools
  • customize dashboard dialog
  • create radiobox group widget - add as style option to select form widget
  • add support for explicit user permissions
  • add ZMCredentials interface following ZMAdminUser and refer to that in ZMAdminSacsHandler (need to implement this for ZMAccount??)
  • move ZMAdminSacsHandler into mvc as generic user/role based authorization handler
  • ZMRuntime::getContext() -> context could be something to delegate all bean creation to - almost full IoC... would also allow to create custom context class
  • feed context from yaml - IoC definition file(s)
  • upgrade all catalog manager plugins, drop catalog_manager group
  • clean up old admin pages (remove) also boxes, etc
  • standalone admin builds?
  • convert ZMCatalogContentController into base class (or have base implementation too)
  • make qe update work - where is the data going (form etc urls need to point to the controller directly and the view has to know to point back to the catalog page??)
  • update plugin properties to reflect changes to moved catalog_manager plugins
  • Review install/readme in context of mod/full/admin release build
  • overflow of catalog manager view area (for example QE)
  • make catalog manager work

pages to do [next?]

  • access control management with multiple views:
    • role permissions
    • user permissions
    • request config
  • product type management
  • catalog manager (plus plugins)
  • custom plugin pages
  • edit customer
  • split ezpages admin into
    • CMS: pages with content only (also some sort of hierarchy management; ie. TOC)
    • menu manager: allow to add/remove/sort menu entries; an entry can be either a URL (relative/absolute) or an existing page
  • configure role permissions for each request - also allow to add requests not mapped (just in case)

upgrade notes

  • delete admin/includes/content folder before uploading new files (will be replaced, but with less files)
Retrieved from "http://wiki.zenmagick.org/index.php/Dev:storefront-admin_code_sharing"
Personal tools