Jazz Web UI and Dojo
I have been told that there are reasons why the Jazz Web UI chooses to
mostly define their own widgets as opposed to using existing dojo Widgets.
Could you compose a written reply on this topic? Also, I know that there are
some few instances like DatePicker where you choose to use the existing
dojoWidget. Could you point me to an example of using the dojo Widget as
opposed to defining my own which I already have from the Jazz Web UI
tutorials?
--
Thanks,
Rosa
mostly define their own widgets as opposed to using existing dojo Widgets.
Could you compose a written reply on this topic? Also, I know that there are
some few instances like DatePicker where you choose to use the existing
dojoWidget. Could you point me to an example of using the dojo Widget as
opposed to defining my own which I already have from the Jazz Web UI
tutorials?
--
Thanks,
Rosa
One answer
Hello Rosa, there are a number of reasons why the Jazz web UI does not *currently* use or extend Dojo widgets.
Historical Reasons
When we decided to use Dojo (~ Jan 2006), Dojo widgets were relatively immature (I believe this was circa Dojo 0.1 or 0.2), so it was more productive to write our own special-purpose widgets rather than trying to make Dojo's generic, and at the time buggy, widgets work for us.
As you may know, we are in the process of upgrading to Dojo 0.9. Like the rest of Dojo, the widget system (now called Dijit) has been completely overhauled and there seem to be many improvements over Dojo v0.4.
I expect to revisit our use (or non-use) of Dojo widgets sometime in the near-future.
Architectural Reasons
As you may know, the Jazz Web UI is fully dynamic - it learns about contributed code when you load the web UI and loads all UI elements programmatically. Because of this, no one builds a monolithic HTML page with embedded Dojo logic; every unit of UI is created directly as a DOM call (document.createElement) or indirectly by the Dojo widget system parsing a widget template and generating DOM nodes based on the template.
Because of this architecture, it's much simpler for components to define units of UI as Dojo widgets rather than building up UI chunks via raw DOM code. This is because the Dojo Widget template system allows us to code the majority of the UI structure in HTML; in other words a declarative UI model vs. the procedural model of writing a bunch of DOM calls by hand.
The net of this is that every non-trivial piece of UI in the Jazz Web UI is implemented as a Dojo widget (just to make use of the declarative widget template system). So there will always be a lot of 'custom' Jazz widgets.
Relevance Reasons
Some widgets are so Jazz-specific that it makes no sense to consider reusing a Dojo widget. A good example of this is the 'Add Subscribers' dialog of the work item web UI. In this case we actually use a Dojo widget (FloatingPane) as a container, but then embed a custom Jazz widget to provide the UI for looking up and adding subscribers to a work item.
Hope this helps.
Historical Reasons
When we decided to use Dojo (~ Jan 2006), Dojo widgets were relatively immature (I believe this was circa Dojo 0.1 or 0.2), so it was more productive to write our own special-purpose widgets rather than trying to make Dojo's generic, and at the time buggy, widgets work for us.
As you may know, we are in the process of upgrading to Dojo 0.9. Like the rest of Dojo, the widget system (now called Dijit) has been completely overhauled and there seem to be many improvements over Dojo v0.4.
I expect to revisit our use (or non-use) of Dojo widgets sometime in the near-future.
Architectural Reasons
As you may know, the Jazz Web UI is fully dynamic - it learns about contributed code when you load the web UI and loads all UI elements programmatically. Because of this, no one builds a monolithic HTML page with embedded Dojo logic; every unit of UI is created directly as a DOM call (document.createElement) or indirectly by the Dojo widget system parsing a widget template and generating DOM nodes based on the template.
Because of this architecture, it's much simpler for components to define units of UI as Dojo widgets rather than building up UI chunks via raw DOM code. This is because the Dojo Widget template system allows us to code the majority of the UI structure in HTML; in other words a declarative UI model vs. the procedural model of writing a bunch of DOM calls by hand.
The net of this is that every non-trivial piece of UI in the Jazz Web UI is implemented as a Dojo widget (just to make use of the declarative widget template system). So there will always be a lot of 'custom' Jazz widgets.
Relevance Reasons
Some widgets are so Jazz-specific that it makes no sense to consider reusing a Dojo widget. A good example of this is the 'Add Subscribers' dialog of the work item web UI. In this case we actually use a Dojo widget (FloatingPane) as a container, but then embed a custom Jazz widget to provide the UI for looking up and adding subscribers to a work item.
Hope this helps.