Prototype shots of the menubar

The menuButton component will be stateless to the end user and will allow for a form to be submitted when a selection has occurred or an optional single submit; but both submit methods would execute the selected option element's action listener in the invoke application phase of the JSF lifecycle. The component will have now value change event that is publicly accessible by the JSF application developer.

A typeical usage from a JSF app developers point of view would be as follows notice both the action and actionListener events:

<mobi:menuButton buttonLabel="Actions Menu" styleClass="" style=""
itemTitleLabel="Actions" >
<mobi:menuButtonItem action="#

"
actionListener="#

">
  Create Record</mobi:menuButtonItem>
<mobi:menuButtonItem actionListener="#

">
  Update Record</mobi:menuButtonItem>
<mobi:menuButtonItem actionListener="#{someBean.deleteAll">
  Delete All</mobi:menuButtonItem>
</mobi:menuButton>

The renderer output for the component will look something like this:

<div class="mobi-menu-btn ">
<span class="mobi-menu-btn-btn"><span>Actions Menu</span</span>
<select id="j_idt76" class="mobi-menu-btn-menu"
onchange="assignSelected(this);uncheckAll(this);submit(this)">
<option value="j_idt77">Actions</option>
<option value="j_idt81">   Delete Record</option>
<option value="j_idt83">   Submit Record</option>
<option value="j_idt85">   Create Record</option>
<option value="j_idt87">   Update Record</option>
<option value="j_idt89">   Delete All</option>
</select>
<input type="hidden" id="buttonValue" name="buttonValue" />
</div>

For the select component to behave correctly as a button a dummy option element must be inserted as the first record as it is the default selected item and will not generate a onchange event. When any other option is selected the hidden field is updated with the selected value and the selected state of the select element is cleared. Once the hidden field has been updated the form can be submitted, or the button single submitted if configured.

During the menuButton decode the component can match the submitted "selected" hidden value against it's own internal list of actions and actionListeners and queue up the necessary events to fire in the correct JSF phase. The component is stateless and should not echo the hidden field value back in the request.

Addition of simple html/JavaScript prototype to the mobi-comps-dev branch. Demo can be viewed by loading .\icemobile-comps-dev\components\tests\mobitest\src\main\webapp\ajax\menubutton-test.html and is linked on main ajax index page.

Also updated the component showcase on the comp-dev branch to have a place holder slot for a new menuBar example.

found it...will take a look and get component classes done,
created a new branch to reflect new packaging of components and copied things over. Now this resides at :-
server.ice:8888/svn/ossrepo/icemobile/branches/RC1-comps-dev/components/tests/mobitest/src/main/webapp/williams/menubutton-test.html

new branch for comps dev now named RC1-comps-dev

How is the panelConfirmation to be used with the menuItem?
Can I assume that each menuItem will have their own defined panelConfirmation attribute? Otherwise, the panelConfirmation would just be on the menuButton itself, correct?

<mobi:menuButton label="Actions Menu" >
<mobi:menuItem label="command 1" panelConfirmation="pnlConf1Id" actionListener="#

"/>
<mobi:menuItem label="command 2" panelConfirmation="pnlConf1Id" actionListener="#

"/>
</mobi:menuButton>

I think we have to assume that the panelConfirmation will be on the menuItem, as it gives the developer the flexibility t show or not to show a dialog. For example confirmation for "delete" but no confirmation for an "update".

Added menuBar prototype code and example placeholder to mobile showcase. Also added menuButton package to components and the corresponding ipad and honeycomb theme.

A POJO-based menu could be considered. All List instances associated with a given component must be of equal length. The length is checked and any discrepency is logged as a WARNING. If the length of any List is insufficient, that particular feature is ignored for that SelectItem (i.e., no confirmationPanel or actionListener is invoked) :

bean.items returns a List of javax.faces.model.SelectItem

• this provides label and value
  bean.listeners returns a List of String EL references to actionListener methods
• these are interpreted when the component decodes on the server
  bean.confirmations returns a List of String component IDs of confirmation panels
• these are rendered initially to prompt client-side upon menu selection
  bean.value will be set to the selected value of the menu

<mobi:menu value="#

labels="#

" values="#

" actionListeners="#

" confirmations="#

/>

(bean.values is not strictly necessary since the labels would be sufficient for many cases)

but this may not be necessary since SelectItem is a standard JSF Class.