Developing a New Menu
This chapter contains
the following sections:
Creating a new menu
item involves a series of associated tasks:
Define your menus.
write a left hand navigation tree provider.
Write your reports
and make sure they point to your new menu location with the proper context map
Defining a Menu
When using Open
Automation, the only way to add new menus is by providing a file called
menu.xml . The code examples below provide guidance
regarding the task of defining a menu item.
The following code
samples are included in the Open Automation SDK samples. The XML samples show
two options for introducing menu items:
Before You Begin
How to insert
new menu items into existing folders (for example, the
How to add
entirely new menu items into the UI
Every menu node has
a unique integer ID associated with it. When introducing new menu items, be
aware that the following menu IDs are reserved as indicated in the table.
Table 1 System Menu ID
|Physical Infrastructure Policies
Listed below are the
components of a Menu Item:
label - This is
the label displayed in the UI for the menu.
path - This is
the value used in the URL when navigating to the menu.
include a backslash at the end of this string; for example:
op—This is the
permission the user must have in order to access this menu; no_check means
everyone can access it.
always be "modules/GenericModules.swf". This field should only be populated if
it's a menu item NOT category.
leftNavType—Valid values are either "none" or
"backend_provided". We'll discuss what theses values mean in details in a later
section. This field should only be populated if it's a menu item NOT category.
children - If
the menu has more menus underneath it, you add them here. The best practice is
not to have more than three levels in a menu.
Sample values for
the menu item components listed above are provided in the code examples below.
|| Option 1: Add a
new menu item underneath an existing folder; in this case, the one called
When adding a
menu item into an existing menu category, you first have to locate the menuid
of the category to which you want to add the item. In the example, we add the
new menu item under "Virtual", which has the menuid of 1000. Take note of the
parent menu item with just the menuid filled in: this is all you need in order
to signal that you are placing your menu item into an existing category. The
new menu item is placed into the children field.
<!-- this shows you how to add a new menu item underneath virtual -->
<label>Dummy Menu 1</label>
||Option 2: Add an
entirely new menu item into the UI.
If you are
defining an entirely new menu item, provide all the details as shown in the
example. First provide all the details for the menu category, then add all the
child menu items underneath it. The example here shows a menu two levels deep,
but in theory you can go as deep as you want. The best practice is to create
menus no more than three levels deep.
<!-- entirely new menu -->
<label>Sample Menu 1</label>
What to Do Next
Register the menus.
Registering a Menu
Automation, menu registration is handled automatically. As a developer, you
only need to name the xml file of your menu as
menu.xml, then package it as part of your module.
Ensure that the
menu.xml file is at the top level of the module jar
Before You Begin
Define a new menu
item under either a new or an existing folder.
Cisco UCS Director
uses menu navigation to determine what reports and forms to display in the UI.
For more information on the subject of report locations, refer to
Specifying the Report Location.
leftNavType field specifies the type of navigation to be
used in your menu item.
The value none means
No navigation is
The context map
rule associated with the menu item will use type = 10, name = "global_admin".
leftNavType is set to none, the type value and name
value for the context map rule associated with the menu item will come in handy
when you need to register your reports to this menu location!
If the leftNavType
is backend_provided, you must provide an implementation of
populates the left hand navigation tree.
Each node of the
navigation tree will need to provide the following elements:
The navigation tree needs to be associated with a menu ID, so when
registering the tree provider, make sure to use the corresponding menu ID.
the path to an
icon to show in the UI (optional)
type (for more details, see the section about registering report contexts)
the context ID
(this will become the report context ID that you may use when generating
Table 2 System Menu ID
for Virtual Account
Table 3 System Menu ID
for Physical Account
For more details,
refer to code samples.
This topic focuses
on adding new report contexts. When developing new menu items, new report
contexts are crucial: you must register new unique contexts, you CANNOT use
The Open Automation
documentation about defining menu navigation briefly mentions that you need to
provide a report context type when building your left hand navigation tree
Report contexts are
used by the system to determine which reports can be displayed at any point in
the UI. For more background information, refer to the documentation on
specifying report location:
Specifying the Report Location. See also the list of existing
report context data in
For open automation,
there are APIs in place to auto-generate a new report context. Refer to
com.cloupia.feature.foo.FooModule for examples on
registering report contexts and menu providers.
report contexts are not portable. This means that if you deploy your module in
one instance of UCSD and the same module in another instance of UCSD, the
auto-generated report context you get in each instance may have different
values. Thus, any code you write that uses those duplicate values will not
necessarily work! To avoid such problems, use the ReportContextRegistry to
register report contexts and retrieve them.
name, String label), and take a look at the javadocs and sample code
for more detail.
Refer to code
samples and the Specifying Report Location document to see how these report
contexts ultimately end up being used.
Before You Begin
developers who need to register report contexts should first talk to a UCSD
lead. The UCSD lead can provide you with a block of integers reserved
exclusively for your use. This will guarantee that any report contexts you
define are unique. When you have your block, you can use
ReportContextRegistry.register(int type, String name, String
label) to register the new context.