|
Sydney | ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | ||||||||
Object | +--MenuManager
Defined in menu_manager.js
| Constructor Summary | |
MenuManager
(<MenuItemProvider> menuItemProvider, <ContentProvider> contentProvider, <ViewerSorter> sorter)
Creates an object to manage a data-driven menu. |
|
| Method Summary | |
Object
|
getAssociatedObject(<Widget> widget)
Gets the domain object associated with the given Widget.
|
Widget
|
getAssociatedWidget(<Object> object)
Gets the Widget associated with object.
|
ContentProvider
|
getContentProvider()
Returns the ContentProvider associated with this
MenuManager.
|
MenuItemViewer
|
getMenuItemProvider()
Returns the MenuItemProvider associated with this
MenuManager.
|
ViewerSorter
|
getSorter()
|
Widget
|
getWidget()
Returns the Widget displaying this viewer's contents.
|
void
|
setSorter(<ViewerSorter> newSorter, <boolean> forceResort)
Sets this viewer's sorter to be newSorter.
|
| Constructor Detail |
function MenuManager(<MenuItemProvider> menuItemProvider, <ContentProvider> contentProvider, <ViewerSorter> sorter)
MenuManager could be extended to manage a
hierarchy of menus, rather than a single menu, but I can't think of a good
example of a data-driven hierarchy of menus, only a data-driven menu.
Another potential problem is that the most sensible layout for a menu might
have only part of that menu be data-driven, but there is no provision for
"static" members of a managed menu.
One thought that crossed my mind was that MenuItemProvider
could be changed such that getMenuItem(element) be allowed to
return a single MenuItem, an array of MenuItems,
or a list of MenuItems, and then MenuManager could
leverage forEach to insert them into
the menu. Then the content provider could return a fake data-object that
represents a clump of "static" menu items, the menu-item provider could
return a list of menu-items for that object, and the sorter could make sure
that everything ends up in the right place. This arrangement would be
non-trivial to implement, though, because the current insertion mechanism
assumes an isomorphic mapping from indexes into this._elements
and indexes into this.getWidget().children. Of course, this
setup could be overly complicated anyway, and trying to figure out how to
keep such a menu sorted could be the least of anyone's worries.
menuItemProvider - the data-object to MenuItem translator
contentProvider - the data source
sorter - (Optional) - a sorting policy for the data objects. Defaults to a default instance of ViewerSorter.
| Method Detail |
Object getAssociatedObject(<Widget> widget)
Widget.
widget - the Widget to search for
widget
Widget getAssociatedWidget(<Object> object)
Widget associated with object.
Note: if object is null or
undefined, then the returned value is
this.getWidget().
object - the domain object to search for
Widget displaying a value for object
ContentProvider getContentProvider()
ContentProvider associated with this
MenuManager.
ContentProvider
MenuItemViewer getMenuItemProvider()
MenuItemProvider associated with this
MenuManager.
MenuItemProvider for this manager
ViewerSorter getSorter()
Widget getWidget()
Widget displaying this viewer's contents.
Widget
void setSorter(<ViewerSorter> newSorter, <boolean> forceResort)
newSorter. If
newSorter is different from the existing sorter then the
elements in the viewer will be resorted according to the new sorter.
newSorter - a ViewerSorter to start using
forceResort - (Optional) - a boolean to indicate whether or not to force a re-sort. If forceResort is false, then the widgets will only be re-sorted if newSorter is different from the existing sorter. Defaults to false.
|
Sydney | ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | ||||||||