ICEfaces
  1. ICEfaces
  2. ICE-6910

If using a form other than h:form, icefaces does not recognize it.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.2
    • Fix Version/s: 3.0.RC2, 3.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces 2.0.2, Liferay 6.0 EE sp1, Tomcat 6.0.29, AlloyFaces 1.0.1.0

      Description

      I was trying to use <aui:form> to get the alloy styles applied, but when i did, icefaces failed to recognize the form and inject its ajax code.

        Activity

        Lucas Theisen created issue -
        Ken Fyten made changes -
        Field Original Value New Value
        Salesforce Case []
        Fix Version/s 2.1 [ 10241 ]
        Assignee Priority P3
        Assignee Deryk Sinotte [ deryk.sinotte ]
        Hide
        Deryk Sinotte added a comment -

        I might need some additional clarification here. There is documentation about a aui:form tag provided by Liferay:

        http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Alloy+UI+Forms+(aui)
        http://alloy.liferay.com/

        But this doesn't appear to be a JSF tag from what I can determine. If that's the aui:form that is being used, then, since it's not a JSF component with a renderer, it's not going to be possible for ICEfaces to find it in the component tree.

        Neil does allude to an aui:form as port of AlloyFaces. I'm not the familiar with it but it appears that this provides component JSF versions/wrappers of the tags provided by Liferay so that they are represented as actual components.

        Within ICEfaces, code is added to the form by wrapping the FormRenderer in what we call a FormBoost. It's detected on wrapped using the following logic. Does

        Renderer renderer = "javax.faces.Form".equals(family) ? new FormBoost(r) : r;

        In this case, perhaps the aui:form renderer is not declared to be of the javax.faces.Form family? (I haven't checked the AlloyFaces source). If not, then the FormBoost would not be applied.

        Show
        Deryk Sinotte added a comment - I might need some additional clarification here. There is documentation about a aui:form tag provided by Liferay: http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Alloy+UI+Forms+(aui ) http://alloy.liferay.com/ But this doesn't appear to be a JSF tag from what I can determine. If that's the aui:form that is being used, then, since it's not a JSF component with a renderer, it's not going to be possible for ICEfaces to find it in the component tree. Neil does allude to an aui:form as port of AlloyFaces. I'm not the familiar with it but it appears that this provides component JSF versions/wrappers of the tags provided by Liferay so that they are represented as actual components. Within ICEfaces, code is added to the form by wrapping the FormRenderer in what we call a FormBoost. It's detected on wrapped using the following logic. Does Renderer renderer = "javax.faces.Form".equals(family) ? new FormBoost(r) : r; In this case, perhaps the aui:form renderer is not declared to be of the javax.faces.Form family? (I haven't checked the AlloyFaces source). If not, then the FormBoost would not be applied.
        Hide
        Deryk Sinotte added a comment -

        Without additional info or a test case, we'll have to close this case as won't fix. Is the workaround sufficient for this? Is there any additional information that can be provided about how you are using the aui:form - is it the Liferay tag or the AlloyFaces wrapper?

        Show
        Deryk Sinotte added a comment - Without additional info or a test case, we'll have to close this case as won't fix. Is the workaround sufficient for this? Is there any additional information that can be provided about how you are using the aui:form - is it the Liferay tag or the AlloyFaces wrapper?
        Hide
        Lucas Theisen added a comment - - edited

        Sorry Deryk, I missed your first response. Neil Griffen (of the portletfaces bridge project) has started a JSF analog (using JSF UIComponents) to the JSP AlloyUI (the one you refer to with the link above). This is intended to map the styles such that they will be themeable using the same theme stylesheets as JSP pages would. Anyway, the project is called AlloyFaces, and the related forum post is this:

        http://www.portletfaces.org/community/forums/-/message_boards/view_message/57547?_19_threadView=tree

        For me, the workaround is enough, but it means i have to manually add all the additional styles that the AlloyFaces would have done automatically for me. In my opinion, ICEfaces should be able to see that it is a form (whether aui:form, h:form, or any other kind of form) and be able to augment it with the necessary information to make it work. I no longer have my test case as my project moved forward with the workaround, but this issue should not be hard to reproduce. Just create a maven web project, include jsf, alloyfaces, and icefaces. Put an aui:form in the page and an input that has an on change or something then see if icefaces can provide the automatic ajax. If it is necessary, I could probably put a small project together to demonstrate this. Please let me know.

        I will ask Neil to take a look at this thread to see if he is doing something that makes it not a javax.faces.Form family component.

        Show
        Lucas Theisen added a comment - - edited Sorry Deryk, I missed your first response. Neil Griffen (of the portletfaces bridge project) has started a JSF analog (using JSF UIComponents) to the JSP AlloyUI (the one you refer to with the link above). This is intended to map the styles such that they will be themeable using the same theme stylesheets as JSP pages would. Anyway, the project is called AlloyFaces, and the related forum post is this: http://www.portletfaces.org/community/forums/-/message_boards/view_message/57547?_19_threadView=tree For me, the workaround is enough, but it means i have to manually add all the additional styles that the AlloyFaces would have done automatically for me. In my opinion, ICEfaces should be able to see that it is a form (whether aui:form, h:form, or any other kind of form) and be able to augment it with the necessary information to make it work. I no longer have my test case as my project moved forward with the workaround, but this issue should not be hard to reproduce. Just create a maven web project, include jsf, alloyfaces, and icefaces. Put an aui:form in the page and an input that has an on change or something then see if icefaces can provide the automatic ajax. If it is necessary, I could probably put a small project together to demonstrate this. Please let me know. I will ask Neil to take a look at this thread to see if he is doing something that makes it not a javax.faces.Form family component.
        Hide
        Neil Griffin added a comment -

        The AlloyFaces <aui:form> component is a subclass of UIForm.

        See: http://svn.portletfaces.org/svn/portletfaces/alloy/faces/alloyfaces/trunk/src/main/java/org/portletfaces/alloy/faces/component/AUIForm.java
        And: https://svn.java.net/svn/mojarra~svn/tags/2.1.3/jsf-api/src/main/java/javax/faces/component/UIForm.java

        When ICEfaces fortifies form components, would it be able to find the AUIForm component in the tree?

        Show
        Neil Griffin added a comment - The AlloyFaces <aui:form> component is a subclass of UIForm. See: http://svn.portletfaces.org/svn/portletfaces/alloy/faces/alloyfaces/trunk/src/main/java/org/portletfaces/alloy/faces/component/AUIForm.java And: https://svn.java.net/svn/mojarra~svn/tags/2.1.3/jsf-api/src/main/java/javax/faces/component/UIForm.java When ICEfaces fortifies form components, would it be able to find the AUIForm component in the tree?
        Hide
        Deryk Sinotte added a comment -

        Ok, then what is probably happening then is that our FormSubmit class (a SystemEventListener) is bailing due to:

        public boolean isListenerForSource(final Object source) {
        if (!(source instanceof HtmlForm))

        { return false; }

        The processEvent method for this class is the one that adds the script for capturing form submissions for Ajax purposes.

        Show
        Deryk Sinotte added a comment - Ok, then what is probably happening then is that our FormSubmit class (a SystemEventListener) is bailing due to: public boolean isListenerForSource(final Object source) { if (!(source instanceof HtmlForm)) { return false; } The processEvent method for this class is the one that adds the script for capturing form submissions for Ajax purposes.
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #26776 Thu Dec 08 09:01:53 MST 2011 deryk.sinotte ICE-6910: treat forms as UIForms rather than the more specialized HtmlForm so that we can handle a broader spectrum of alternate form implementations
        Files Changed
        Commit graph MODIFY /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/event/FormSubmit.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #26779 Thu Dec 08 10:59:26 MST 2011 deryk.sinotte ICE-6910: treat forms as UIForms rather than the more specialized HtmlForm so that we can handle a broader spectrum of alternate form implementations
        Files Changed
        Commit graph MODIFY /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/event/WindowAndViewIDSetup.java
        Hide
        Deryk Sinotte added a comment -

        Changed the FormSubmit class to handle all form processing as UIForm types rather than HtmlForm types. This way we'll handle a broader range of alternate form implementations.

        Show
        Deryk Sinotte added a comment - Changed the FormSubmit class to handle all form processing as UIForm types rather than HtmlForm types. This way we'll handle a broader range of alternate form implementations.
        Deryk Sinotte made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Salesforce Case []
        Affects [Compatibility/Configuration]
        Ken Fyten made changes -
        Fix Version/s 3.0.RC2 [ 10313 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Lucas Theisen
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: