Opened 16 years ago
Closed 16 years ago
#117 closed task (fixed)
Widget Architecture change
| Reported by: | pagameba | Owned by: | madair |
|---|---|---|---|
| Priority: | P1 | Milestone: | 2.0 |
| Component: | Widgets | Version: | 1.0.6 |
| Severity: | Blocker | Keywords: | |
| Cc: | Browser: | All | |
| External ID: | Operating System: | All | |
| state: | New |
Description
The current architecture of how widgets are represented, activated and deactivated is convoluted, difficult to work with, and inefficient in some cases.
In the current code, widgets can be either exclusive on the map (put the map into some *mode*) or not. Widgets that are exclusive are registered as such with the map object and the map handles deactivating the current widget when a new widget is activated (that is exclusive).
The Zoom widget is a sub-class of Fusion.Tool.ButtonBase which allows the widget to represent itself as a button. This is fine for the normal case of putting the widget in a toolbar. However, the widget can also appear in a menu (think context menu on the map). In the menu case, we end up creating a Zoom widget that has a button object that is never used and manually create a MenuItem for the widget that bypasses the button. The coding for this is tricky and we end up with a lot of unnecessary object creation.
I am going to modify the internal architecture of existing widgets and the base classes to create a cleaner interface for this. At the core of the change will be the addition of some new members to the Widget class:
- uiClass - this is expected to be either null (the default for widgets that aren't represented by a button or menu) or a Jx class (either Jx.Button or Jx.Menu). This will replace both Fusion.Tool.ButtonBase and Fusion.Tool.MenuBase classes and the inheritance/initialization in the actual widgets.
- activate - an empty function to be overridden by subclasses that is called by the uiClass object in the case of a widget being a button or menu item. This combines what would have previously been the activate and execute methods in some Widget sub-classes into a single method. Widgets that were not mutually exclusive had an execute method that is now renamed to activate.
- deactivate - an empty function to be overridden by subclasses that is triggered on a mutually exclusive button when another mutually exclusive widget is activated. This is then used by widgets that establish some set of event handlers to do clean up when deactivated.
- uiObj - the user interface object that represents this object
- setUiObject - a method that assigns a user interface object (button, menu item or DOM element) to a the widget. This should be overridden by subclasses that want to do something to the ui object (such as place menu items in the menu that was created for them). Previously this would have happened in the widget's initialize method but the ui object is now not available until *after* the widget has been created.
This will require changes to all existing widgets that inherit from ButtonBase or MenuBase and some other widgets. In addition, the responsibility for creating a user interface object for a widget is now moved from the widgets to the ApplicationDefinition.js code where the widgets are initially created.
(In [1493]) rework widget core architecture to be more friendly (See #117)