Breadcrumbs

Breadcrumbs show hierarchical way to the current page, not a history of user. Its logic is more clear and most of it is only in one Mixin, not scattered throughout the code.

Table of Contents

• Design
  • Explorer screens
  • Non-explorer screens
• Usage

Design

• First, show the path from the navigation (E.g.: Compute > Infrastructure > Providers)
• Only breadcrumbs which lead somewhere should be clickable (last breadcrumb in the menu, etc.)
• Show header in the breadcrumb as the last breadcrumb
• Consistent position across all screens

Explorer screens

• Show the tree path in the breadcrumbs includes accordion header

Default

Detail

Detail action

Action

Tagging/Ownership/etc.

• Show the item breadcrumb only when there is only one item

One item

More items

Ancestry

• only Services. Services are missing hiearchy in the tree (because of performance).

Filters

• are not a part of the hiearchy

Non-explorer screens

Default

• There could be different header on the landing page, should be included in the menu part (however two controllers are using dynamic headers: hosts, clusters.)

Detail

• Instead of the header show item breadcrumb

When wrong ...Menu Breadcrumbs > Item > Header Compute > Infrastructure > Providers > HyperV > HyperV (Summary)

When right ...Menu Breadcrumbs > Item Compute > Infrastructure > Providers > HyperV

Why not use a header instead of a item? This is because of nesting. The header part is lost when a user clicks on some action and so the breadcrumbs would change from:

Compute > Infrastructure > Providers > Infrastructure Providers > HyperV (Summary)

to:

Compute > Infrastructure > Providers > Infrastructure Providers > HyperV > Edit Infrastructure Providers 'HyperV'

Detail Action/Action

Tagging/Ownership/etc.

• Show item breadcrumb only when there is only one item

One item

More items

Usage

A controller should include Breadcrumbs mixins:

include Mixins::BreadcrumbMixin

and then it has to define a new method:

def breadcrumbs_options

• which returns a hash with variables depended on the controller and its type:

{
:breadcrumbs    => ..., 
:include_record => ..., 
:record_info    => ...,
:record_title   => ...,
}

All controllers should contain:

{
:breadcrumbs => [
  { :title => ... , :url => ?, :key => ? }
  ]
}

• which sets a way in the main navigation menu:

• :title - title of the breadcrumb, eg. _('Cloud Providers)'

• :url - url, eg. controller_url

A breadcrumb can have also:

• :key - using in tree views, key for the item, eg. root
• :action - additional action for using with the key, eg. accordion_select

Variables

All variables are optional.

:record_info => @ems

• some controllers use different variables to store information about a current item. Most of them are using @record, which is a default variable. If not, then you have to manually set which variable is used.

:record_title => :key

• Method which stores a title of the variable set in the record_info ( :title = @ems.key )

Explorer controllers

:include_record => true

• when the title of the shown item is missing, e.g. in edit actions. Mostly used when trees do not contain all nodes.

Schema of breadcrumbs flow