Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Orion/Library Independence"

(New page: 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. For UI com...)
 
Line 1: Line 1:
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.  For UI components, or widgets, that we need in the UI, we will consider small, library-independent implementations of the functionality, as well as considering our own implementation.  This document outlines what would be needed to reduce or eliminate our dependence on dojo in favor of adopting newer HTML5 conventions, independent/small UI components, or homegrown small UI components.
+
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.  For UI components, or widgets, that we need in the UI, we will consider 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 intending 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.
  
 
== Advantages of library independence ==  
 
== Advantages of library independence ==  
Line 5: Line 7:
 
* Orion consumers who use the same libraries as us (such as dojo) wish to switch versions at their own pace.   
 
* 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
 
* Size reduction and performance improvements as we eliminate library methods that are already available in the browser
* Simplification of styling so that we aren't combining a library theme with our own themes
+
* Simplified learning curve for consumers
* Simplification and consistency of coding practices so that we aren't wrestling different conventions/life cycles in the UI (dijit lifecycle vs. Orion, dijit layout vs. raw CSS, etc.).
+
** theming doesn't require understanding of library/widget level theming
 +
** 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 ==
 
== Existing dependencies and proposed replacements ==
 
The remainder of this document categorizes our dependencies and gives status on the replacement candidates.
 
The remainder of this document categorizes our dependencies and gives status on the replacement candidates.
=== JavaScript utilities ===
+
=== DOM manipulation ===
==== 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).
We have many dom utility methods sprinkled throughout the client code.  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, dojo.query element.querySelector and element.querySelectorAll
 
* dojo.byId, dojo.query element.querySelector and element.querySelectorAll
 
* dojo.addClass, removeClass, toggle class  element.classList.remove/add/toggle/contains
 
* dojo.addClass, removeClass, toggle class  element.classList.remove/add/toggle/contains
 +
* dojo.connect/disconnect  element.addEventListener/removeEventListener
 +
* dojo.style
 +
* dojo.place
 +
* dojo.create
 +
* dojo.position
 +
* dojo.empty
 +
* dojo.attr, removeAttr
  
==== Other (non DOM) JavaScript utilities ====
+
=== General JavaScript utilities ===
 
* dojo.hitch Function.bind
 
* dojo.hitch Function.bind
 +
* dojo.keys constants
 +
* dojo.trim
 +
 +
=== Deferred / Promise support ===
 +
* dojo.Deferred
 +
* dojo.DeferredList
 +
 +
=== dijit Layout support  ===
 +
* [[Image:Ok_green.gif]] Replace common page use of dijit BorderContainer, ContentPane, Splitter
 +
** switch to CSS based layout
 +
** implement small, lightweight splitter
 +
* Settings page uses custom dijit layouts
 +
* Some pages (compare, shell) use internal dijit layout such as BorderContainer
 +
 +
=== dijit Menu support ===
 +
* Command service should replace dijit implementation
 +
** Replace DropDownMenu, MenuItem, PopupMenu with a simplified dropdown widget
 +
** Replace dijit Tooltip with simplified tooltip
 +
* Replace orion menu extensions
 +
** 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
  
==== Deferred / Promise support ====
+
=== 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
  
=== dijit UI components ===
+
=== move unused dijit-based experiments out of orion repository ===
* dijit BorderContainer, ContentPane, Splitter for page layout.
+
* plugin maker
** BorderContainer, ContentPane and splitter were removed and replaced with CSS and an Orion-specific splitter.js
+
* dijit DropDownMenu, MenuItem
+
* dijit Tooltip
+
* dijit TooltipDialog
+
* dijit Dialog
+

Revision as of 17:01, 7 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. For UI components, or widgets, that we need in the UI, we will consider 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 intending 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.

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
  • Simplified learning curve for consumers
    • theming doesn't require understanding of library/widget level theming
    • 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, dojo.query element.querySelector and element.querySelectorAll
  • dojo.addClass, removeClass, toggle class element.classList.remove/add/toggle/contains
  • dojo.connect/disconnect element.addEventListener/removeEventListener
  • dojo.style
  • dojo.place
  • dojo.create
  • dojo.position
  • dojo.empty
  • dojo.attr, removeAttr

General JavaScript utilities

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

Deferred / Promise support

  • dojo.Deferred
  • dojo.DeferredList

dijit Layout support

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

dijit Menu support

  • Command service should replace dijit implementation
    • Replace DropDownMenu, MenuItem, PopupMenu with a simplified dropdown widget
    • Replace dijit Tooltip with simplified tooltip
  • Replace orion menu extensions
    • 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

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

Back to the top