Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0, 2.1
    • Fix Version/s: 2.2 Sprint 12
    • Component/s: Components/Renderers
    • Labels:
      None

      Description

      <paul_dijou> I have read about JSF 2.2 supporting HTML5, great news
      <paul_dijou> But I was wondering
      <paul_dijou> Does it includes support for custom tag attributes (like "data-xxx")

      1. 20120515-2322-i_spec_1089.patch
        185 kB
        Ed Burns
      2. 20120516-2342-i_spec_1089.patch
        205 kB
        Ed Burns
      3. 20120625-i_spec_1089-snapshot.patch
        22 kB
        Ed Burns
      4. 20120716-1550-i_spec_1089.patch
        40 kB
        Ed Burns
      5. 20120717-0052-i_spec_1089.patch
        58 kB
        Ed Burns

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          <paul_dijou> Another idea would be that JSF component have a "data" attribute
          <paul_dijou> Which could accepte Map<String,String> or JSon or just plain String correctly formated
          <paul_dijou> And so <h:graphicImage src="..." data="

          {tooltip:value, test:test}

          "/> would produce <img src="..." data-tooltip="value" data-test="test"/>
          <paul_dijou> (I think HAML syntax do something no far away from that)

          <paul_dijou> Here you go :

          http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#html5_custom_data_attributes

          <paul_dijou> Of course, you can have nested properties :data => {:test => {:sub1 => "val1", :sub2 => "val2"}} will result in : data-test-sub1="val1" data-test-sub2="val2"

          Show
          Ed Burns added a comment - <paul_dijou> Another idea would be that JSF component have a "data" attribute <paul_dijou> Which could accepte Map<String,String> or JSon or just plain String correctly formated <paul_dijou> And so <h:graphicImage src="..." data=" {tooltip:value, test:test} "/> would produce <img src="..." data-tooltip="value" data-test="test"/> <paul_dijou> (I think HAML syntax do something no far away from that) <paul_dijou> Here you go : http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#html5_custom_data_attributes <paul_dijou> Of course, you can have nested properties :data => {:test => {:sub1 => "val1", :sub2 => "val2"}} will result in : data-test-sub1="val1" data-test-sub2="val2"
          Hide
          Frank Caputo added a comment -

          I've already done it in a project by simply wrapping the ResponseWriter. Not that flexible and a bit hacky:

          public class Html5ResponseWriter extends ResponseWriterWrapper {

          private ResponseWriter wrapped;

          public Html5ResponseWriter(ResponseWriter wrapped)

          { this.wrapped = wrapped; }

          @Override
          public ResponseWriter getWrapped()

          { return wrapped; }

          @Override
          public ResponseWriter cloneWithWriter(Writer writer)

          { return new Html5ResponseWriter(super.cloneWithWriter(writer)); }

          @Override
          public void startElement(String name, UIComponent component) throws IOException {
          super.startElement(name, component);
          if(component == null)

          { return; }

          Map<String,Object> attributes = component.getAttributes();
          for (Map.Entry<String, Object> entry : attributes.entrySet()) {
          String key = entry.getKey();

          if(key.startsWith("data-") || key.equals("placeholder") || key.equals("pattern")) {
          Object value = entry.getValue();
          if(value != null)

          { writeAttribute(key, value, key); }

          }
          }
          }
          }

          Show
          Frank Caputo added a comment - I've already done it in a project by simply wrapping the ResponseWriter. Not that flexible and a bit hacky: public class Html5ResponseWriter extends ResponseWriterWrapper { private ResponseWriter wrapped; public Html5ResponseWriter(ResponseWriter wrapped) { this.wrapped = wrapped; } @Override public ResponseWriter getWrapped() { return wrapped; } @Override public ResponseWriter cloneWithWriter(Writer writer) { return new Html5ResponseWriter(super.cloneWithWriter(writer)); } @Override public void startElement(String name, UIComponent component) throws IOException { super.startElement(name, component); if(component == null) { return; } Map<String,Object> attributes = component.getAttributes(); for (Map.Entry<String, Object> entry : attributes.entrySet()) { String key = entry.getKey(); if(key.startsWith("data-") || key.equals("placeholder") || key.equals("pattern")) { Object value = entry.getValue(); if(value != null) { writeAttribute(key, value, key); } } } } }
          Hide
          Ed Burns added a comment -

          snapshot

          Show
          Ed Burns added a comment - snapshot
          Hide
          Ed Burns added a comment -

          AS> Ed -
          AS> I find the use of JSON here very confusing and unnecessarily complex.

          AS> Two simpler options that I would prefer:

          AS> 1. Enhance f:attribute to allow pass-thru of data- attributes, eg:

          AS> <h:outputText>
          AS> <f:attribute name="data-andy-rocks" value="false"/>
          AS> </h:outputText>

          AS> Thinking the <f:attribute> handler would populate a map that hangs off
          AS> of the component's attribute map. Renderers would be required to
          AS> iterate over this map and blast out all of attributes.

          AS> 2. Add a new f:dataAttribute tag, eg:

          AS> If we prefer not to complicate <f:attribute>, we could do:

          AS> <h:outputText>
          AS> <f:dataAttribute name="andy-rocks" value="false"/>
          AS> </h:outputText>

          AS> With a similar implementation.

          AS> Ideally either/both of these would support EL-binding, eg:

          AS> <h:outputText>
          AS> <f:dataAttribute name="andy-rocks" value="#

          {bean.doesAndyRockYet}

          "/>
          AS> </h:outputText>

          AS> Regarding:

          >> If the view being rendered is not HTML5, the value of this attribute
          >> must be ignored.

          AS> I would lean towards passing these through regardless of the target
          AS> markup language. Although data- attributes are not strictly valid
          AS> pre-HTML5, simply dropping these might make life more difficult for an
          AS> app developer who needs to target a range of browsers (including both
          AS> HTML5 and pre-HTML5 browsers).

          Show
          Ed Burns added a comment - AS> Ed - AS> I find the use of JSON here very confusing and unnecessarily complex. AS> Two simpler options that I would prefer: AS> 1. Enhance f:attribute to allow pass-thru of data- attributes, eg: AS> <h:outputText> AS> <f:attribute name="data-andy-rocks" value="false"/> AS> </h:outputText> AS> Thinking the <f:attribute> handler would populate a map that hangs off AS> of the component's attribute map. Renderers would be required to AS> iterate over this map and blast out all of attributes. AS> 2. Add a new f:dataAttribute tag, eg: AS> If we prefer not to complicate <f:attribute>, we could do: AS> <h:outputText> AS> <f:dataAttribute name="andy-rocks" value="false"/> AS> </h:outputText> AS> With a similar implementation. AS> Ideally either/both of these would support EL-binding, eg: AS> <h:outputText> AS> <f:dataAttribute name="andy-rocks" value="# {bean.doesAndyRockYet} "/> AS> </h:outputText> AS> Regarding: >> If the view being rendered is not HTML5, the value of this attribute >> must be ignored. AS> I would lean towards passing these through regardless of the target AS> markup language. Although data- attributes are not strictly valid AS> pre-HTML5, simply dropping these might make life more difficult for an AS> app developer who needs to target a range of browsers (including both AS> HTML5 and pre-HTML5 browsers).
          Hide
          paul_dijou added a comment -

          I agree that having <f:attribute> is easier to read and to understand but it's have its own problem :

          • it's quite verbose
          • it's not really dynamic if you need to put condition on what you should pass to the data attribute. You would probably need a "rendered" attribute on the <f:attribute>, and it would become quite heavy.
          • why does most of attributes are in the original tag and just some of them need to use <f:attribute> ?
          • should the <f:attribute> support any attribute ?

          I'm fine with the "data" attribute and I like the current patch. However, does the current implementation support EL ?

          <h:outputText value="Test" data="{toggle: #{bean.dataToggle}, hide: #{bean.hide}}" />
          

          IMO, it should be ok to write this code.

          For the record, I was discussing the subject with RichFaces guys, here is a summary : https://issues.jboss.org/browse/RF-12177

          Show
          paul_dijou added a comment - I agree that having <f:attribute> is easier to read and to understand but it's have its own problem : it's quite verbose it's not really dynamic if you need to put condition on what you should pass to the data attribute. You would probably need a "rendered" attribute on the <f:attribute>, and it would become quite heavy. why does most of attributes are in the original tag and just some of them need to use <f:attribute> ? should the <f:attribute> support any attribute ? I'm fine with the "data" attribute and I like the current patch. However, does the current implementation support EL ? <h:outputText value= "Test" data= "{toggle: #{bean.dataToggle}, hide: #{bean.hide}}" /> IMO, it should be ok to write this code. For the record, I was discussing the subject with RichFaces guys, here is a summary : https://issues.jboss.org/browse/RF-12177
          Hide
          Kim Haase added a comment -

          It's important for accessibility that generated layout tables should support the role attribute, particularly role="presentation", which indicates to screen readers that the table is used for layout rather than data. If the panelGrid tag doesn't specifically support the tag, it should be allowed on a pass-through basis.

          This requirement is based on section 1194.22(a) of the 508 requirement, "A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content)." (See http://www.access-board.gov/sec508/guide/1194.22.htm#%28a%29.) Oracle has a number of specific requirements that implement this rule, including the rule about the role="presentation" attribute; I imagine other companies do too.

          Show
          Kim Haase added a comment - It's important for accessibility that generated layout tables should support the role attribute, particularly role="presentation", which indicates to screen readers that the table is used for layout rather than data. If the panelGrid tag doesn't specifically support the tag, it should be allowed on a pass-through basis. This requirement is based on section 1194.22(a) of the 508 requirement, "A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content)." (See http://www.access-board.gov/sec508/guide/1194.22.htm#%28a%29 .) Oracle has a number of specific requirements that implement this rule, including the rule about the role="presentation" attribute; I imagine other companies do too.
          Hide
          Ed Burns added a comment -

          Simple implementation in place. Please see JAVASERVERFACES-2449 for complete test coverage.

          Show
          Ed Burns added a comment - Simple implementation in place. Please see JAVASERVERFACES-2449 for complete test coverage.
          Hide
          Ed Burns added a comment -

          I can't get this to stay closed. People keep coming up with new features.

          Show
          Ed Burns added a comment - I can't get this to stay closed. People keep coming up with new features.
          Hide
          Ed Burns added a comment -

          Let's see if it stays closed now!

          Show
          Ed Burns added a comment - Let's see if it stays closed now!
          Hide
          Ed Burns added a comment -

          Additional work required for f:selectItem and f:selectItems

          Show
          Ed Burns added a comment - Additional work required for f:selectItem and f:selectItems
          Hide
          Ed Burns added a comment -

          snapshot

          Show
          Ed Burns added a comment - snapshot
          Hide
          Ed Burns added a comment -

          Revision 10288 seems to have the required fixes for f:selectItem and f:selectItems.

          Show
          Ed Burns added a comment - Revision 10288 seems to have the required fixes for f:selectItem and f:selectItems.
          Hide
          Manfred Riem added a comment -

          Closing resolved issue out

          Show
          Manfred Riem added a comment - Closing resolved issue out

            People

            • Assignee:
              Ed Burns
              Reporter:
              Ed Burns
            • Votes:
              8 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 3 days
                3d
                Remaining:
                Time Spent - 1 day, 7 hours, 15 minutes Remaining Estimate - 1 day, 16 hours, 45 minutes
                1d 16h 45m
                Logged:
                Time Spent - 1 day, 7 hours, 15 minutes Remaining Estimate - 1 day, 16 hours, 45 minutes
                1d 7h 15m