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.'

  • No labels