It might make sense to make an enumeration, or constants in a utility class, to be more explicit about what the defaults should be, and when we're diverging from them. Eg:

public final static String COMMAND_DEFAULT_EXECUTE = "@all";
public final static String COMMAND_DEFAULT_RENDER = "@all";

Changes for defaultExecute:

Accordion : panechange : @all ==> @this
Dialog : close : @all ==> @this
Droppable : drop : @all ==> @this + other(draggable)
List : migrate : @all ==> @this + other(List)
NotificationPanel : display / close : @all ==> @this
Resizable : resize : @all ==> @this
TabSet : serverSideTabChange : @all ==> @this + other(if tabSetProxy)
Tooltip : display : @all ==> @this
AutocompleteEntry : * : @all ==> @this
CheckboxButton : activate : @all ==> @this
DateTimeEntry : dateSelect : @all ==> @this
MaskedEntry : blur : @all ==> @this
RichTextEntry : save : @all ==> @this
SimpleSelectOneMenu : * : @all ==> @this
SliderEntry : * : @all ==> @this
TableConfigPanel : * : @all ==> @this + other(dataTable)
DataExporter : activate : @all ==> @this + other(dataTable)

Changes for defaultRender:
Draggable : start : @none === Document why @none keeps it from glitching
MaskedEntry : keypress : @none === Document why @none keeps it from glitching, having focus problems
ProgressBar : complete / cancel / change : @this ==> @all
TextEntry, TextEntryArea : blur : @this -> @all
ThemeSelect : valueChange : @this === Document that this is done on client, and execute/render is just to sync with server with what's already done

Also, with comboBox, textEntry, textAreaEntry, selectMenu, simpleSelectOneMenu are we using the different events per browser like icecore:singleSubmit does? focusout for older IE.

The following done:

M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\datetimeentry\DateTimeEntryMeta.java#34222
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\maskedentry\MaskedEntryMeta.java#34222
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\textareaentry\TextAreaEntryMeta.java#34222
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\textentry\TextEntryMeta.java#34222
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\themeselect\ThemeSelectMeta.java#34222

I'd like to mention a usability issue with ace:textEntry that we recently ran into, that has potential ramifications here.

Consider the following use-case:

<h:panelGroup id="firstNameField">
    <ace:textEntry id="firstName" required="true" value="#{modelBean.firstName}">
        <ace:ajax render="firstNameField" />
    </ace:textEntry>
    <h:message for=firstName" />
</h:panelGroup>

When the user tabs-out of the field with no value, they will immediately be presented with a "Value is required" type of error message. This is because the default value for the execute attribute is "blur" for ace:textEntry. This has the same behavior as ICEfaces 1.8 partialSubmit.

However, h:inputText works differently... consider the same use case with h:inputText and f:ajax...

<h:panelGroup id="firstNameField">
    <h:inputText id="firstName" required="true" value="#{modelBean.firstName}">
        <f:ajax render="firstNameField" />
    </h:inputText>
    <h:message for=firstName" />
</h:panelGroup>

When the user tabs-out of the field with no value, they don't see the error message. This is because the default value for execute is "change" instead of "blur".

So my recommendation would be that the default value of execute for ace:textEntry be "change" just like h:inputText, and that ace:textEntry have the ability to support execute="change" and execute="blur" just like h:inputText. Right now, ace:textEntry doesn't even support execute="change" which is very problematic.

Thanks Neil, this jira is more about the executing and rendering defaults, but it was good to hear your input on the change event. There are some cross browser and input versus select reasons why we didn't do a simple onchange dom event client event, but we're looking at making what we call a synthetic event that will be basically a fixed onchange that will work in all scenarios.

My pleasure Mark. Thanks for considering.

Revision #34224
Committed by nils.lundquist
2 minutes ago ICE-9123 - Update ace:checkbox defaultExecute

Committed the following changes at revision 34241:

defaultExecute
Accordion : panechange : @all ==> @this
Dialog : close : @all ==> @this
Droppable : drop : @all ==> @this + other(draggable)
NotificationPanel : display / close : @all ==> @this
Resizable : resize : @all ==> @this
Tooltip : display : @all ==> @this
AutocompleteEntry : * : @all ==> @this
RichTextEntry : save : @all ==> @this
SimpleSelectOneMenu : * : @all ==> @this
SliderEntry : * : @all ==> @this
DataExporter : activate : @all ==> @this + other(dataTable)

defaultRender
Draggable : start : @none === Document why @none keeps it from glitching
ProgressBar : complete / cancel / change : @this ==> @all

It seems like the only changes left to do are these, for defaultExecute.
List : migrate : @all ==> @this + other(List)
TabSet : serverSideTabChange : @all ==> @this + other(if tabSetProxy)
TableConfigPanel : * : @all ==> @this + other(dataTable)

Changed with my last two commits to this JIRA:

defaultRender
ace:list select/deselect/move -> @all
ace:dataTable editSubmit -> @all

defaultExecute
ace:tableConfigPanel open/cancel -> @this
ace:tableConfigPanel submit -> @this (+ dynamic table id)
ace:list migrate -> @this (+ dynamic destination list id)