Difference between revisions of "Orion/Library Independence"

From Eclipsepedia

Jump to: navigation, search
(DOM manipulation)
(Existing dependencies and proposed replacements)
Line 90: Line 90:
 
=== dijit Layout support  ===
 
=== dijit Layout support  ===
 
* [[Image:Ok_green.gif]] Replace common page use of dijit BorderContainer, ContentPane, Splitter  
 
* [[Image:Ok_green.gif]] Replace common page use of dijit BorderContainer, ContentPane, Splitter  
** switch to CSS based layout
+
** [[Image:Ok_green.gif]] switch to CSS based layout
** implement small, lightweight splitter
+
** i[[Image:Ok_green.gif]] mplement small, lightweight splitter
 
* Settings page uses custom dijit layouts
 
* Settings page uses custom dijit layouts
 
* Some pages (compare, shell) use internal dijit layout such as BorderContainer
 
* Some pages (compare, shell) use internal dijit layout such as BorderContainer

Revision as of 15:36, 20 November 2012

For Orion 2.0, we are investigating client side implementations that do not depend on a particular javascript library, and instead use raw HTML5/CSS3 constructs where possible.

At the DOM manipulation level, this is made largely possible by our adoption of IE10 for Orion 2.0, since it includes many HTML5 features that were not available in in IE9. Since we no longer need to rely on shims and other workarounds for missing features, we should be able to use the browser native API for things like events, CSS class manipulation, etc.

For UI components, or widgets, that we need in the UI, we will look at existing small, library-independent implementations of the functionality, as well as considering our own implementation. Any custom implementations should be as small/simplified as possible, satisfying Orion use cases but not starting out with the intention to be an independently consumable component.

This document outlines what would be needed to reduce or eliminate our dependence on dojo in favor of these other approaches.

Contents

Advantages of library independence

  • Orion consumers wish to make their own choices regarding JavaScript libraries and UI plugins, and do not wish to bring in other libraries (such as dojo) when they depend on a different library.
  • Orion consumers who use the same libraries as us (such as dojo) wish to switch versions at their own pace.
  • Size reduction and performance improvements as we eliminate library methods that are already available in the browser, as well as eliminating JavaScript and CSS code that we no longer need.
  • Simplified learning curve for consumers
    • theming doesn't require understanding of a separate library/widget level theming mechanism
    • we don't force consumers to learn multiple conventions/life cycles in the UI (dijit lifecycle vs. Orion, dijit layout vs. raw CSS, etc.).

Existing dependencies and proposed replacements

The remainder of this document categorizes our dependencies and gives status on the replacement candidates.

DOM manipulation

We extensively use the dojo.* utility methods. Many of these are now available in our supported browser set. The following list shows method usage and replacement (this may expand to its own page).

  • dojo.byId
document.getElementById(id);
  • dojo.query
element.querySelector(selector, parentNode);
element.querySelectorAll(selector, parentNode);
  • dojo.addClass, removeClass, toggleClass
element.classList.add('class');  // one at a time
element.classList.remove('class');
element.classList.contains('class');
element.classList.toggle('class'); 
  • dojo.connect/disconnect
element.addEventListener/removeEventListener
  • dojo.style
element.style.visibility = "hidden";
element.style.left = "1px";
  • dojo.place
For node placement, use the addChild/appendChild/insertBefore DOM equivalents.  If placing HTML, use innerHTML, or convert to dynamic DOM node creation when security is an issue. 

(See bug bug 392469 for security discussion).

  • dojo.create
  • dojo.position
node.getBoundingClientRect()
  • dojo.empty
  • dojo.attr, removeAttr

General JavaScript utilities

  • dojo.hitch Function.bind
  • dojo.keys constants
  • dojo.trim

hash and hash change

  • dojo.hash, hashchange events - use HTML5 equivalents

i18n utilities

  • dojo.string substitution

Deferred / Promise support

  • dojo.Deferred (use orion.Deferred)
  • dojo.DeferredList

dijit Menu support

  • bug 393813
    • Ok green.gif Command service should replace dijit implementation
      • Ok green.gif Replace DropDown, MenuItem, PopupMenu with a simplified dropdown widget
      • Replace dijit Tooltip with simplified tooltip
    • Ok green.gif Replace orion menu extensions
      • Ok green.gif orion.UserMenu functionality supported by new dropdown + styling

dijit Dialogs

  • replace dijit.Dialogs with simple div-based equivalent
    • client templating of content
    • conversion of all existing Orion dijit dialogs (approximately 20)
  • small js add-ons for special features
    • modal support
    • lightweight, automatic dismissal

dijit Layout support

  • Ok green.gif Replace common page use of dijit BorderContainer, ContentPane, Splitter
    • Ok green.gif switch to CSS based layout
    • iOk green.gif mplement small, lightweight splitter
  • Settings page uses custom dijit layouts
  • Some pages (compare, shell) use internal dijit layout such as BorderContainer

Orion custom dijits

  • domain-specific widgets don't need a framework, replace with application level code
    • plugin related widgets (plugin entry, plugin list, service carousel)
    • site editor
  • settings layout widgets replaced with CSS/splitter (SettingsContainer, SplitSelectionLayout)
  • settings custom field widgets (TextField, Select, Toggles, Buttoms) replaced with HTML5 dom elements
  • settings section moved to existing Orion section support

move unused dijit-based experiments out of orion repository

  • plugin maker