|
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 MenuItem
s,
or a list of MenuItem
s, 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 |