Judy given the current implementation of compat panelConfirmation. What is the path of least resistance to make the component work with any Command input component?

The client has requested that the confirmation should also be assgnable to menutItem in a menuBar, see MOBI-151

Since the menu component that is proposed (MOBI-151) is in actuality a select OneMenu, the event is on the list itself (and will probably use SelectItems as menuItems), this makes integrating this popup a little (a lot??) trickier than having a true menu component with menuItem components which trigger their own events.

Basically the PanelConfirmation can be rendered similarly but where to trigger the popup? and then the actual triggering of the correct event may have to occur back in the application logic.
Also, the "for" would be for the entire component (selectOneMenu).
Should MOBI-156 do a true menu component with menuItems, that would definitely simplify things as then the event that the menuItem triggers can then be dealt with in js (a panelConfirmation could be entirely triggered on the client as there really is no need to have this state on the server) and once the acceptance has occurred, the event would be submitted via whatever way is required (singleSubmit, mobi:ajax, whatever).
The compat panelConfirmation is basically a stylized table that is triggered once a button has been pressed (or in the MOBI-156) the valuechange event is triggered. The panelConfirmation attribute (for compat) is an attribute on the component which will trigger the confirmation to "popup". so in the current case, we would only have an "on change" and the js would then be responsible for setting the correct styles on the div of the table to be shown or the hidediv panel to hide depending on the button pressed on the confirmation panel.

Will assume we would be supporting:-
title, message, acceptLabel, cancelLabel
Need to know which of these attributes we will be supporting:-
type(acceptOnly? cancelOnly? has both accept and cancel?), autoCenter, draggable, displayAtMouse.

The logic for the menu would have to be processed in the application based upon the on change event though (that's not a strength of the proposed menu component in MOBI-151).

Judy could you please try running the compat showcase or the old 1.8.x. showcase and fool around with the bean code. The behaviour is quite well defined, if a panelConfirmation is assigned to a commandButton it will differ execution of the action/actionListenr (will not submit the form) until the the users agrees. This is classic command pattern.

My original question for you was how difficult would it be to assign a panelConfirmation to something other then a comandButton, don't worry about the other bugs created for the client, it's a generic how could it be done? What are options? Can we make the current implemenation work in mobi?

must make sure to take into account mobi:ajax so users can specify separate execute and render attributes. If panelConfirmation is used, singleSubmit will not be enabled.

what makes things tricky here is the following line:-

The client has requested that the confirmation should also be assgnable to menutItem in a menuBar, see MOBI-151

Keeping in mind performance on mobile device am using the following model:-
if event type is "click" or "touchstart"...very straight forward.
if event type is "change", then have to get from config object passed in the correct values for message and accept label, etc to render popup. Once popup accept is trigger then submit the event ('change') with the id of the select menu.
Will have to do similar manipulation in the decode of the menu to accommodate this.

Am working on a panelConfirmation for mobi:commandButton as base case for non-'on change' events...
Can either pass a config object will contain {{option1message, option1acceptlabel, option1 canelobject},

,

...but this is pretty lengthy, so might then render panelConfirmation with the div markups which pertain to each option.
Will use multiple command buttons to see how both of these affect performance on mobile devices.

Original compat used <table> markup which is not currently recommended. Also used prototype js library, so other than attributes and way to tie the confirmation panel with the UICommand, not sure how much more we can take out of it.
Will work on prototype

I don't like the idea of a config object, it makes the component feel heavy. Addition of labels via attributes avoid having to create a backing bean. People really like this component becuase you can insert as a one liner in your app and you good to go, no extra config, no packing beans etc.

Attributes on compat component that we will not support on the mobile version of panelConfirmation.

autoCenter - component will render its self close to centre of page using css.
binding - skip this one until we get a request for it.
displayAtMouse - doesn't apply to mobile
draggable - do point implementing this one at this time.

See svn\ossrepo\icemobile\branches\RC1-comps-dev\samples\mobileshowcase\src\main\webapp\resources\components\panelConfirmation.xhtml for a full listing of attirbutes.

I added the new auto center/scroll code to the panelConfirmation component. I also removed the configureable auto center and made it always on by default. We can add it back in people scream for it, I just can't think of a usage case where it would be useful in mobile.