Menus migration to RichFaces 4

M5 planning

This document will describe the migration of toolBar, dropDownMenu, panelMenu, contextMenu(not M5), menuGroup and menuitem components migration.

 

information from 3.3.x:

 

references:

http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html/rich_dropDownMenu.html

http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html/rich_toolBar.html

tld:

http://docs.jboss.org/richfaces/latest_3_3_X/en/tlddoc/rich/dropDownMenu.html

http://docs.jboss.org/richfaces/latest_3_3_X/en/tlddoc/rich/toolBar.html

 

svn:

http://anonsvn.jboss.org/repos/richfaces/branches/community/3.3.X/ui/dropdown-menu

 

Related requests and jiras:

list of jira's

 

Overview

Toolbar, DropDownMenu and menu-components and panelMenu planned for migration in M5. So in sections only features of those component mentioned. Looks like the components alsmost has no problems from design point of view in 3.3.x(according to jira review). So most of the attributes should be kept as is (any changed ones will be discussed during impl and highlighted there)

DropDownMenu

Attributes list

DIA diagramm available at design folder

 

Base component for menuItem

It should be based on UICommand and accept parameters attached to it.

It should populate ActionEvent and provides action and actionListener support.

 

Base functionality - to be implemented in M5
  • General structure of DDM: Label element defined through facet(label) or label attribute and popup menu list attached to it as for 3.3.x.
    • popup menu constructed using nested menu components:
      • item
      • group
      • separator
  • Item/Group structure
    • icon - label representation
    • should be possible to remove icons elements at all(all the line which holds icons) using css.
    • label should be possible to define using simple label attribute or nested components
      • we should be aware that nested components could consist of block elements.
      • we should support inputs/checkboxes inside menu items (in both label and icon part)
        • we are not responsible for stopping the submission events in case inputs placed to item and getting clicked for editing.
    • icon - attributes and facets for customization.
    • Item should also accept nested components and encode them to label part.
  • Menu items as standalone components for usage in toolbar
  • Three modes for submit: ajax, server, client
    • in case of client mode - developer responsible for sending requests via nested item components, custom JS or behaviors.
  • Bubbling selection from nested groups to the top menu
  • Disabled state
    • whole menu
    • item
    • group
  • JS API (called at ddmenu component)
    • show
    • hide
    • activate(menuItemId)

 

Questionable

Long Term
  • new mode which will works similarry to h:link for item?
  • client-side templating - as for all similar components postponed.
  • lazy loading of nested groups.
    • cached variant
  • iteration tag for population of menu components dynamically
    • some adaptors to build from hierarchical model?
  • access keys to call menu, call menu item.
  • Directions and attachments points customization for both main popup and groups
    • automatical positioning if not enough space for default directions
  • Base keyboard navigation between items and groups
  • Client api
    • show menu
    • hide menu
    • activate item
    • more?
  • Ability to customize "folder" icons.

Toolbar

Base functionality - to be implemented in M5

 

  • renaiming toolBar tag to toolbar as it's simple word and should not use came case. - for bugfix phase.
  • direct child for toolbar without usage toolbar group should be supported and all the items should be encoded one by one from left to right.
  • toolbar group should be used to align the child items to the left or right side of the toolbar
  • there should be possibitlity to add event handlers and styling for child components (actually placed on cells with that components)
    • onitem* events should present at group and toolbar
    • itemClass should present at group and toolBar
  • it should be possible to set separators at group and toolbar level
    • itemSeparator attribute should present at both components.
    • separators defined at toolbar should be encoded between childs of toolvar(no matter if that toolbar group or some other component)
    • separators defined at toolbarGroup level should be encoded between that group items
    • next standard separators should be predefined:
      • none
      • disk
      • grid
      • line
    • none should be default
    • custom URI in attribute should be supported.

Panel Menu

Base functionality - to be implemented in M5
  • General structure of panelMenu
    • panelMenu - wrapper component which defines whole menu attributes. Accepts panelMenuItem and panelMenuGroup as child components.
    • panelMenuGroup - wrapper component for set of items or other groups
    • panelMenuItems - analogoiuys to DDM menuItem. Based on UICommand. Accepts child components which should be encoded at label area.
  • Design structure
    • menuGroup and menuItem consist of two icons(right and left side) and label between them.
      • icons for each side defined with different pairs of attributes and not show by default
      • predefined set of icons:
        • grid
        • disc
        • chevronUp
        • chevronDown
        • triangle
        • triangleUp
        • triangleDown
      • Custom icons could be set using URI to image.
      • label defined using label attribute
  • Top level groups
    • migrated as in 3.3.x. Still contains different design and uses special attributes for customization.
  • Modes
    • groups and items supports three modes - ajax, server and client.
    • For groups it means that theem loads their inner content to the page and switches on client side (client mode) or fetches content only when expanded(ajax, server)
      • Groups also populates ActionEvent and provides action and actionListener the same as item in order to be possible to use it for navigation.
    • For items ajax and server mode means that them will function as common UICommand or Ajax command components with respect to all attributes and events.
    • For items client mode means that nested components, custom JS or behaviors should handle clicks on that items.
  • Disablement
    • complete menu, specific groups and items could be disabled.
  • Groups expansion
    • expandSingle attribute controls if only one group could be expanded in the same time.
  • Selection should be kept in the activeItem attribute value binding
    • bubbleSelection attribute additionally defines if parent nodes of the menu should also have selected look and feel.
  • Server side events
    • ActionEvent populated by group or item in ajax and server mode.
    • ItemChangeEvent populated on selection change and contains information about previously selected item or group and new one.
  • Attributes inheritance
    • almost all the attributes styling, events, mode and so on could be defined at panelMenu level. So them will be applied to all the corresponding components except ones where redefined explicitly
      • e.g. itemMode=ajax and some modes could redefine to server using its own mode attribute.

 

List of attributes