Issue Details (XML | Word | Printable)

Key: ICE-5651
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Ted Goddard
Reporter: Deryk Sinotte
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
ICEfaces

Need to support <f:ajax disabled="true"/>

Created: 22/Apr/10 02:03 PM   Updated: 03/Jan/11 04:18 PM
Component/s: Components, Framework
Affects Version/s: 2.0-Alpha2
Fix Version/s: 2.0-Beta1, 2.0.0

Environment: ICEfaces 2.0 JSF 2.0
Issue Links:
Dependency
 

Affects: Compatibility/Configuration


 Description  « Hide
Standard JSF 2, by default, does not enable Ajax functionality in its components. The f:ajax tag is provided to indicate that you want a component (like a button or a whole form) to use Ajax techniques to submit information and update the interface. ICEfaces, by default, enables components to use Ajax but is also designed to work with the f:ajax tag so that certain behaviours can be modified through attributes on the tag. ICEfaces can also be disabled at the page-level so that standard JSF functionality can be configured on pages where ICEfaces and/or Ajax might not be desired.

What is not currently supported with ICEfaces is disabling Ajax support at a more granular level - ie per component. The f:ajax tag has a 'disabled' attribute, which, if set to true, should disable Ajax features for that component. In these cases, the ICEfaces framework and components should respect when disabled=false and not provide Ajax functionality.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Ted Goddard added a comment - 22/Apr/10 02:15 PM
<f:ajax> is described in the JSF 2.0 specification section 10.4.1.1 table 10-3.

For the disabled attribute in particular:

"false" indicates the Ajax behavior script should be rendered; "true" indicates the Ajax behavior script should not be rendered. "false" is the default.

Ted Goddard added a comment - 09/Jun/10 04:17 PM

The following code dumps out the disabled state of the ajax behavior attached to a given component:

import javax.faces.component.UIComponentBase;
import javax.faces.component.behavior.ClientBehavior;
import javax.faces.component.behavior.AjaxBehavior;

        Map <String, List <ClientBehavior>> behaviors = ((UIComponentBase) component).getClientBehaviors();
        AjaxBehavior behavior = (AjaxBehavior) behaviors.get("action").get(0);
        System.out.println("behaviors found " + behaviors);
        System.out.println("behavior " + behavior + " " + behavior.isDisabled());

So, the <f:ajax> tag is not directly accessible itself, but it creates the AjaxBehavior Object attached to the component which does have an extensive API.

Actual use of this API would need to iterate over all component behaviors and test for AjaxBehavior instances.

Ted Goddard added a comment - 10/Jun/10 05:21 PM
This appears to work for both the nested and the wrapping forms:

    <f:ajax execute="button1" render="pg1 pg2" >
        <h:commandButton id="button1" value="Show/Hide"
                         actionListener="#{basic.toggle}" >
        </h:commandButton>
    </f:ajax>


        <h:commandButton id="button1" value="Show/Hide"
                         actionListener="#{basic.toggle}" >
           <f:ajax execute="button1" render="pg1 pg2" />
        </h:commandButton>

Ted Goddard added a comment - 14/Jun/10 05:40 PM

<f:ajax disabled="true"/> must cause the "capture submit" behavior of the ICEfaces bridge to be disabled for that one component.

HTML5 supports custom data-* attributes (which are frowned upon but not actually prohibited in HTML currently):

http://dev.w3.org/html5/spec/elements.html#embedding-custom-non-visible-data

For instance the bridge callback added by ice.captureSubmit() could check for the presence of data-ice-ajax="disabled" on the submitting element, and if present allow full-page form submission to proceed normally.

Alternatively, the component could render JavaScript event callbacks that would set a flag, however this would result in verbose markup due to the variety of events that can cause form submission to occur.

Ted Goddard added a comment - 30/Jun/10 06:27 PM

Part of the change to application.js required that the onsubmit callback not always be erased; it's not clear why this was necessary before.

--- core/src/main/javascript/application.js (revision 21816)
+++ core/src/main/javascript/application.js (working copy)
@@ -169,16 +169,21 @@
             f.submit = function() {
                 submit(null, f);
             };
- f.onsubmit = none;
+// f.onsubmit = none;
             each(['onkeydown', 'onkeypress', 'onkeyup', 'onclick', 'ondblclick', 'onchange'], function(name) {
                 f[name] = function(e) {
                     var event = e || window.event;

Ted Goddard added a comment - 30/Jun/10 06:28 PM
Is the f.onsubmit = none necessary in some conditions?

Ted Goddard added a comment - 30/Jun/10 06:29 PM
Server code takes UINamingContainer.getSeparatorChar() into account, but client-side script does not. Perhaps this is available from the jsf.js API. If not, it should be.

Mircea Toma added a comment - 01/Jul/10 10:49 AM - edited
Theoretically, it seems that 'f.onsubmit = none' is not necessary. There are certain events (within certain browsers) that are not canceling the default action even if they are told so. See 'click' event for example, 'Prevent Default' section: http://www.quirksmode.org/dom/events/click.html .
Also, to avoid any browser specific issues the 'onsubmit' is disabled in case the 'submit' event is generated by the browser during capturing phase instead of bubbling phase. See: http://www.quirksmode.org/js/events_order.html .

Ted Goddard added a comment - 01/Jul/10 11:52 AM
Can we reproduce a problem in a certain browser with that line commented out? It will make the f:ajax disabled more complex to implement (we will need to conditionally set f.onsubmit to none in both places).

Ted Goddard added a comment - 01/Jul/10 02:32 PM
<f:ajax disabled="true"> has no effect in basic, but is verified working in auction.

Ted Goddard added a comment - 01/Jul/10 03:57 PM
commandLink is not currently functional: the "onclick" is being handled by the span contained within the commandLink, so is not found in the "disabled" list.

Joanne Bai added a comment - 02/Jul/10 11:11 AM
Verified successfully the reload button on the icefaces.jsf page using

Glimmer revision 21833
Servers: Tomcat 6.0.26, Glassfish v3 with Mojarra 2.0.2 jars
Browsers: FF3.6, IE8

Ted Goddard added a comment - 06/Jul/10 11:58 AM
commandLink is now supported.

Note that <f:ajax disabled="false"> will often have undesirable side effects -- this will result in the JSF 2.0 Ajax defaults being applied (such as execute and render "this").

Optimizations are possible beyond the current implementation: when detecting commandLink, all disabled elements are tested for the existence of hidden fields with that identical name and value. This could be restricted to commandLink elements only.