Cocoon
  1. Cocoon
  2. COCOON-1825

Ajax error when an active state widget become invisible state widget

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.9
    • Fix Version/s: 2.1.12, 2.2.1
    • Component/s: Blocks: Forms
    • Labels:
      None
    • Other Info:
      Patch available
    • Affects version (Component):
      Blocks: Forms - 1.0.0-RC3-SNAPSHOT
    • Fix version (Component):
      Blocks: Forms

      Description

      Some widget (field with selection-list and styling=radio, group, etc...) can not be hidden (state=invisible)in ajax mode.

      I declare some widgets without state attribute in the form definition, my form is in ajax mode, when I set the widget state to INVISIBLE, the ajax response can not be applied to the form because <span id="widget-name">...</span> is not available in source code.

      I think about 2 patches :
      *putting a <span></span> in forms-field-styling.xsl where is not set
      *or modifing abstractWidgetDefinition.java in ordre to generate a placeholder around each widget (but patch seems to need a lot of modification in forms-field-styling.xsl too)



      Here is the patch for first

      --- forms-field-styling.orig 2006-04-13 15:37:06.590221200 +0200
      +++ forms-field-styling.xsl 2006-04-13 15:38:22.525291200 +0200
      @@ -198,8 +198,9 @@
           <xsl:variable name="value" select="fi:value"/>
           <xsl:variable name="vertical" select="string(fi:styling/@list-orientation) != 'horizontal'"/>
           <xsl:choose>
      - <xsl:when test="$vertical">
      - <table id="{$id}" cellpadding="0" cellspacing="0" border="0" title="{fi:hint}">
      + <xsl:when test="$vertical">
      + <span id="{$id}">
      + <table id="{$id}" cellpadding="0" cellspacing="0" border="0" title="{fi:hint}">
                 <xsl:for-each select="fi:selection-list/fi:item">
                   <xsl:variable name="item-id" select="concat($id, ':', position())"/>
                   <tr>
      @@ -224,6 +225,7 @@
                   </tr>
                 </xsl:for-each>
               </table>
      + </span>
             </xsl:when>
             <xsl:otherwise>
               <span id="{$id}" title="{fi:hint}">
      @@ -682,22 +684,24 @@
             | know where to insert the widget if it becomes visible
             +-->
         <xsl:template match="fi:placeholder">
      - <span id="{@id}"/>
      + <span id="{@id}"><xsl:apply-templates/></span>
         </xsl:template>
         
         <!--+
             | fi:struct - has no visual representation by default
             +-->
         <xsl:template match="fi:struct">
      - <xsl:apply-templates/>
      + <span id="{@id}"><xsl:apply-templates/></span>
         </xsl:template>
       
         <!--+
             | fi:group - has no visual representation by default
             +-->
         <xsl:template match="fi:group">
      - <xsl:apply-templates/>
      + <span id="{@id}"><xsl:apply-templates/></span>
         </xsl:template>
      +
      +
       
         <xsl:template match="@*|node()" priority="-1">
           <xsl:copy>




      Here for the second


      --- AbstractWidget.orig 2006-04-13 15:31:07.851701200 +0200
      +++ AbstractWidget.java 2006-04-13 15:30:31.446616200 +0200
      @@ -483,6 +483,10 @@
           public void generateSaxFragment(ContentHandler contentHandler, Locale locale)
           throws SAXException {
       
      + AttributesImpl placeHolderAttrs = new AttributesImpl();
      + placeHolderAttrs.addCDATAAttribute("id", getRequestParameterName());
      + contentHandler.startElement(FormsConstants.INSTANCE_NS, "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder", placeHolderAttrs);
      +
               if (getCombinedState().isDisplayingValues()) {
                   // FIXME: we may want to strip out completely widgets that aren't updated when in AJAX mode
                   String element = this.getXMLElementName();
      @@ -497,15 +501,9 @@
       
                   generateItemSaxFragment(contentHandler, locale);
       
      - contentHandler.endElement(FormsConstants.INSTANCE_NS, element, FormsConstants.INSTANCE_PREFIX_COLON + element);
      -
      - } else {
      - // Generate a placeholder that can be used later by AJAX updates
      - AttributesImpl attrs = new AttributesImpl();
      - attrs.addCDATAAttribute("id", getRequestParameterName());
      - contentHandler.startElement(FormsConstants.INSTANCE_NS, "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder", attrs);
      - contentHandler.endElement(FormsConstants.INSTANCE_NS, "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder");
      + contentHandler.endElement(FormsConstants.INSTANCE_NS, element, FormsConstants.INSTANCE_PREFIX_COLON + element);
               }
      + contentHandler.endElement(FormsConstants.INSTANCE_NS, "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder");
           }
       
        public Object getAttribute(String name) {

        Activity

        Hide
        Antonio Gallardo added a comment -
        Should I need to apply both patched or just one?
        Show
        Antonio Gallardo added a comment - Should I need to apply both patched or just one?
        Hide
        Sylvain Wallez added a comment -
        I don't see how surrounding the <table> with a <span> changes something. Or... I remember of a bug in IE that doesn't like tables to be replaced in JavaScript or something related.

        Adding an element for <fi:group> and <fi:struct> is good, but I'm wondering if this should be a <div> rather than a <span>.

        <fi:placeholder> are used to mark the place of hidden widgets and should be kept empty.
        Show
        Sylvain Wallez added a comment - I don't see how surrounding the <table> with a <span> changes something. Or... I remember of a bug in IE that doesn't like tables to be replaced in JavaScript or something related. Adding an element for <fi:group> and <fi:struct> is good, but I'm wondering if this should be a <div> rather than a <span>. <fi:placeholder> are used to mark the place of hidden widgets and should be kept empty.
        Hide
        Vincent Demay added a comment -
        I think the better is the first one : putting a span around each element. So you can apply only the first one on forms-field-styling.xsl.

        Thanks.

        Show
        Vincent Demay added a comment - I think the better is the first one : putting a span around each element. So you can apply only the first one on forms-field-styling.xsl. Thanks.
        Hide
        Antonio Gallardo added a comment -
        IN the first part of the patch, there is:

        + <span id="{$id}">
        + <table id="{$id}" cellpadding="0" cellspacing="0" border="0" title="{fi:hint}">

        I don't think it is a good idea to have the same id in 2 different elements. It seems like it might blow somewhere else.

        how we can fix this?
        Show
        Antonio Gallardo added a comment - IN the first part of the patch, there is: + <span id="{$id}"> + <table id="{$id}" cellpadding="0" cellspacing="0" border="0" title="{fi:hint}"> I don't think it is a good idea to have the same id in 2 different elements. It seems like it might blow somewhere else. how we can fix this?
        Hide
        Guillaume Déflache added a comment -
        About Antonio's last comment: I think Vincent needs to tell us why he added a 'span' element with the 'id' attribute when there already was the 'table' element to "hook" the 'id' attribute to. Was that really to workaround an IE bug as Sylvain suggested, or was only a copy/paste error?

        To sum up, for the others modifications IMHO:
        1) "fi:placeholder" should be left alone as Sylvain said
        2) "fi:group" and "fi:struct" should use a "div" element instead of a "span" one, because if we do so:
           i) hope to validate Cocoon Forms HTML generated pages remains: spans cannot contain block markup, whereas divs can contain both inline and block markup, so nested "div-fi:*'s" are more likely to produce valid HTML
           ii) this is consistent with the way "fi:union" is already handled
           also:
           iii) for rendering issues, these divs can always be made inline in CSS if needed
           iv) in practice groups (and structs? never used them) almost always are block-level anyway...
         3) BTW the "fi:imagemap" template probably also lacks an "id" attribute... and I have not checked "advanced" styling, there could be more missing... (BTW isn't GoogleMap widget _advanced_ styling!?!)

        So I volunteer to redo the 1st proposed patch with all above suggestions applied! :)
        But please Vincent do tell us what was your purpose with the "double-id" thingy!

        BTW perhaps someone could add "[PATCH]" in the subject (and fix the typo...) to show a patch is available?
        Show
        Guillaume Déflache added a comment - About Antonio's last comment: I think Vincent needs to tell us why he added a 'span' element with the 'id' attribute when there already was the 'table' element to "hook" the 'id' attribute to. Was that really to workaround an IE bug as Sylvain suggested, or was only a copy/paste error? To sum up, for the others modifications IMHO: 1) "fi:placeholder" should be left alone as Sylvain said 2) "fi:group" and "fi:struct" should use a "div" element instead of a "span" one, because if we do so:    i) hope to validate Cocoon Forms HTML generated pages remains: spans cannot contain block markup, whereas divs can contain both inline and block markup, so nested "div-fi:*'s" are more likely to produce valid HTML    ii) this is consistent with the way "fi:union" is already handled    also:    iii) for rendering issues, these divs can always be made inline in CSS if needed    iv) in practice groups (and structs? never used them) almost always are block-level anyway...  3) BTW the "fi:imagemap" template probably also lacks an "id" attribute... and I have not checked "advanced" styling, there could be more missing... (BTW isn't GoogleMap widget _advanced_ styling!?!) So I volunteer to redo the 1st proposed patch with all above suggestions applied! :) But please Vincent do tell us what was your purpose with the "double-id" thingy! BTW perhaps someone could add "[PATCH]" in the subject (and fix the typo...) to show a patch is available?
        Hide
        Antonio Gallardo added a comment -
        I asked about the duplicated id just to be sure, but I believe it is a typo.
        I agree it is better to use div instead of span.
        Sure feel free to send a patch. I will be glad to apply it. :-)
        Show
        Antonio Gallardo added a comment - I asked about the duplicated id just to be sure, but I believe it is a typo. I agree it is better to use div instead of span. Sure feel free to send a patch. I will be glad to apply it. :-)
        Hide
        Vincent Demay added a comment -
        I think this simple patch could resolve the issue :

        Index: C:/Program Files/Eclipse3.01/workspace/forms/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
        ===================================================================
        --- C:/Program Files/Eclipse3.01/workspace/forms/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (revision 464244)
        +++ C:/Program Files/Eclipse3.01/workspace/forms/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (working copy)
        @@ -730,14 +730,18 @@
               | fi:struct - has no visual representation by default
               +-->
           <xsl:template match="fi:struct">
        - <xsl:apply-templates/>
        + <div id="{@id}">
        + <xsl:apply-templates/>
        + </div>
           </xsl:template>
         
           <!--+
               | fi:group - has no visual representation by default
               +-->
           <xsl:template match="fi:group">
        - <xsl:apply-templates/>
        + <div id="{@id}">
        + <xsl:apply-templates/>
        + </div>
           </xsl:template>
         
           <xsl:template match="@*|node()" priority="-1">
        Show
        Vincent Demay added a comment - I think this simple patch could resolve the issue : Index: C:/Program Files/Eclipse3.01/workspace/forms/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl =================================================================== --- C:/Program Files/Eclipse3.01/workspace/forms/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (revision 464244) +++ C:/Program Files/Eclipse3.01/workspace/forms/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (working copy) @@ -730,14 +730,18 @@        | fi:struct - has no visual representation by default        +-->    <xsl:template match="fi:struct"> - <xsl:apply-templates/> + <div id="{@id}"> + <xsl:apply-templates/> + </div>    </xsl:template>      <!--+        | fi:group - has no visual representation by default        +-->    <xsl:template match="fi:group"> - <xsl:apply-templates/> + <div id="{@id}"> + <xsl:apply-templates/> + </div>    </xsl:template>      <xsl:template match="@*|node()" priority="-1">
        Hide
        Antonio Gallardo added a comment -
        Would you provide a full patch? The latest looks like a partial patch without the initial patch.
        Show
        Antonio Gallardo added a comment - Would you provide a full patch? The latest looks like a partial patch without the initial patch.
        Hide
        Jörg Heinicke added a comment -
        The fix for fi:group was already in SVN, just broken in Cocoon 2.2/Cocoon Forms 1.0/1.1 (COCOON-2204). Applied fix for fi:struct.
        Show
        Jörg Heinicke added a comment - The fix for fi:group was already in SVN, just broken in Cocoon 2.2/Cocoon Forms 1.0/1.1 ( COCOON-2204 ). Applied fix for fi:struct.

          People

          • Assignee:
            Jörg Heinicke
            Reporter:
            Vincent Demay
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development