ICEfaces
  1. ICEfaces
  2. ICE-4614

Standard JSF Ajax compatibility

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Alpha1
    • Fix Version/s: 2.0-Alpha2, 2.0.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces, non-ICEfaces
    • Workaround Exists:
      Yes
    • Workaround Description:
      Hide
      Use ICEfaces everywhere.
      Show
      Use ICEfaces everywhere.

      Description

      ICEfaces should not interfere with the Ajax functions of non-ICEfaces pages.

        Issue Links

          Activity

          Hide
          Deryk Sinotte added a comment -

          Support for standard ajax is part of the overall support for partial page processing.

          Show
          Deryk Sinotte added a comment - Support for standard ajax is part of the overall support for partial page processing.
          Hide
          Lucas Theisen added a comment -

          Really? The only workaround is to: "Use ICEfaces everywhere."? This is a problem as I have a portal which mixes all kinds of portlets. Some are jsp, some jsf, and some jsf with icefaces. The problem is those that are just plain jsf have all of their ajax requests hijacked by icefaces. This is causing failures here:

          function configurationOf(element) {
          return detect(parents(element),
          function(e)

          { >>> return e.configuration; }

          ).configuration;
          }

          Since the portlet did not have the icefaces jar, it did not inject the .configuration property that this method is looking for, so this function actually returns null and any attempt to make a call against the returned value will fail. Is there a way to tell icefaces to ignore this portlet? Or more to the point could you have icefaces only hijack the functions of portlets that have the icefaces jar in their lib?

          Show
          Lucas Theisen added a comment - Really? The only workaround is to: "Use ICEfaces everywhere."? This is a problem as I have a portal which mixes all kinds of portlets. Some are jsp, some jsf, and some jsf with icefaces. The problem is those that are just plain jsf have all of their ajax requests hijacked by icefaces. This is causing failures here: function configurationOf(element) { return detect(parents(element), function(e) { >>> return e.configuration; } ).configuration; } Since the portlet did not have the icefaces jar, it did not inject the .configuration property that this method is looking for, so this function actually returns null and any attempt to make a call against the returned value will fail. Is there a way to tell icefaces to ignore this portlet? Or more to the point could you have icefaces only hijack the functions of portlets that have the icefaces jar in their lib?
          Hide
          Lucas Theisen added a comment -

          A little more investigation shows that this is done when icefaces registers an onEvent handler through a call to jsf.ajax.addOnEvent. Perhaps the handler method could fail gracefully if the configuration is not found that way the request could proceed and jsf ajax could work even with icefaces adding that handler? It seems that icefaces interfering with other non-icefaces content is a major design flaw.

          Show
          Lucas Theisen added a comment - A little more investigation shows that this is done when icefaces registers an onEvent handler through a call to jsf.ajax.addOnEvent. Perhaps the handler method could fail gracefully if the configuration is not found that way the request could proceed and jsf ajax could work even with icefaces adding that handler? It seems that icefaces interfering with other non-icefaces content is a major design flaw.
          Hide
          Ted Goddard added a comment -

          This is an old JIRA and is closed because the original investigation was complete. Could you create a new JIRA that describes your use case and the problem you see? Is ICEfaces attempting to modify a non-ICEfaces form?

          Show
          Ted Goddard added a comment - This is an old JIRA and is closed because the original investigation was complete. Could you create a new JIRA that describes your use case and the problem you see? Is ICEfaces attempting to modify a non-ICEfaces form?
          Hide
          Lucas Theisen added a comment -

          I created this ticket:

          http://jira.icefaces.org/browse/ICE-7168

          Basically, icefaces is adding a handler via jsf.ajax.addOnEvent, which will get processed for ALL requests on the page even those coming from non-icefaces portlets. It would be ok, if it detected when the request was NOT from an icefaces form and failed gracefully allowing the actual request to complete and be handled by the non-icefaces requester.

          Show
          Lucas Theisen added a comment - I created this ticket: http://jira.icefaces.org/browse/ICE-7168 Basically, icefaces is adding a handler via jsf.ajax.addOnEvent, which will get processed for ALL requests on the page even those coming from non-icefaces portlets. It would be ok, if it detected when the request was NOT from an icefaces form and failed gracefully allowing the actual request to complete and be handled by the non-icefaces requester.

            People

            • Assignee:
              Judy Guglielmin
              Reporter:
              Ted Goddard
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: