THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
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.'