DISCLAIMER: These are old notes, and do not necessarily reflect the current development plan for the UI widget framework.
Widgets: new syntax
-------------------
For better namespacing/organization and better readability, widgets
are implemented via a custom 'jquery-ish' factory, instead of as a
jQuery module. This is mainly to keep the widgets abstracted away from
whatever DOM element they are associated with.
So, for example, the browser widget before:
var $browser = $('#browser'); $browser.cloudBrowser(); // Add panel $browser.cloudBrowser('addPanel', { ... }); $browser.cloudBrowser('selectPanel', { ... });
...and now:
var browser = cloudUI.widgets.browser({ $container: $('...'), $navigation: $('...'), ... }); browser.addPanel({ ... }); browser.selectPanel({ ... });
– This basically avoids namespace conflicts with other potential
jQuery modules, and is a bit easier to understand
Widgets: general philosophy
---------------------------
-UI-centric: widgets' focus is mainly on UI and manipulation of
visual elements on the page, as opposed to data/backend (such as
AJAX calls, etc.). Make sure there are lots of ways to control a
widgets' behavior
-Extensibility: every possible operation can be hooked into, for
flexibility to add custom behavior. Even in the core default widget
sets, complex features, such as action handling, for specific widgets
should be modularized into separate JS components, which extend the
base widget via hooks.
-Centralized data handling / protocol: obviously the widgets are meant
to work with AJAX and data sets, but these operations should be
regulated through separate modules in the main application layer, to
ensure that data is passed to/from AJAX and implmenetation code
consistently. For example, a separate module should handle context
handling and creating a response object.
-Loose coupling & isolation: All widgets should be useful in
isolation, so that other users can pick and choose which
functionality suits their needs. They should not require a specific
layout to be in place in order to work. Complex features as part of
the core widget set, such as action handling, for specific widgets
should be modularized into separate JS components, which extend the
base widget code via hooks.
Application
-----------
-For users that want a full, ready-to-use UI layout and flow
-Used primarily for CloudStack + other products that have a similar
UI/UX
List view changes
-----------------
-Does not use browser anymore: all 'flow' handling (such as launching
a detail view, shortcuts, etc.) should be handled in application
-More operations for controlling row-level behavior:
- Set/unset row loading state
- Update row data
- Remove row
- Add row
- Disable row
- etc.
-All rows can be identified with an ID (i.e., CloudStack API object
ID), to support data matching between other UI elements, such as
actions currently being performed, etc. – allows for statefulness
-Allow updating a row not only by passing jQuery '$row' object, but
also by ID + any other field param. This way a row can be manipulated
if the $row reference isn't available, (such as when re-loading the
widget but the item's data is known), and multiple rows can be
handled (such as all items matching a specific field, etc.)
-Have complex features handled by extension, instead of all in the
main widget code. The list view should only handle basic table
rendering and data retrieval. This also includes new potential
features (quick view popup, etc.). Possibly also modularize table
resizing and other extra 'eye candy.'