Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.2 Sprint 8
    • Fix Version/s: None
    • Component/s: Components/Renderers
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      627
    • Status Whiteboard:
      Hide

      cat2 renderkitdoc size_small importance_small

      Show
      cat2 renderkitdoc size_small importance_small

      Description

      I think the handling of column classes of the h:dataTable is not consistent.
      Looking at the code on the calling page, you have the 'columnClasses' attribute
      on the one side and h:column tags within the xhml body on the other side. Both
      should correspond to each other, especially because the data type displayed in
      the column and it's visual style are closely connected (e.g. you would
      right-justify a number type and display booleans as a checkbox-like symbol).

      I now you decide, that you want to use the 'rendered' attribute on some of the
      h:column subelements to temporarily hide those columns, the mapping between
      columns and its style class should not be lost. But this is the case with the
      current implementation.

      A static columnClasses attribute should do and should stay consistent with the
      static h:column tags in the xhtml code. The dynamic behaviour should happen on
      the serverside, rendering subsets of the given columns should also consider the
      right subset of the given columnClasses.

      Note that instead of putting comma-separated styleClass names into the attribute
      of the h:dataTable the spec could also allow to put them as a single-valued
      styleClass attribute directly into the corresponding h:column subelement – the
      whole issue would not exist then.

      So IMHO it's an unnecessary implementation effort to constantly supply an
      appropriate sublist (also needed to be converted to a comma-separted string) as
      a dynamic 'columnClasses' attribute to h:dataTable.

      [see also JSF-2-RI issue 1258 at
      https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1258 – Contrary to
      my misleading comment there this not a matter of whether PPR/ajax is used or not]

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          Move to unscheduled target milestone

          Show
          Ed Burns added a comment - Move to unscheduled target milestone
          Hide
          Ed Burns added a comment -

          Prepare to delete "spec" subcomponent.

          Show
          Ed Burns added a comment - Prepare to delete "spec" subcomponent.
          Hide
          mojavelinux added a comment -

          Link issues.

          Show
          mojavelinux added a comment - Link issues.
          Hide
          mojavelinux added a comment -

          Update milestone and component.

          Show
          mojavelinux added a comment - Update milestone and component.
          Hide
          Ed Burns added a comment -

          DG> +1. columnClasses is clumsy for large tables, and h:column's lack of style
          DG> and styleClass is non-intuitive. We have to make it clear which has
          DG> precedence between h:dataTable's columnClasses and h:column's styleClass,
          DG> though.

          Show
          Ed Burns added a comment - DG> +1. columnClasses is clumsy for large tables, and h:column's lack of style DG> and styleClass is non-intuitive. We have to make it clear which has DG> precedence between h:dataTable's columnClasses and h:column's styleClass, DG> though.
          Hide
          Ed Burns added a comment -

          Here's the first on this. From Craig McClanahan in 2002:

          CM> Attribute "columnClasses" - Some renderers support an attribute of
          CM> this name, which contains a comma-delimited list of CSS style
          CM> classes that will be used in sequence. If a rendered table has more
          CM> columns than the number of class names in this list, it will be
          CM> restarted from the beginning as many times as needed. However, the
          CM> first column in a new row will always be rendered with the first
          CM> class listed here.

          But then, interestingly, David Geary says, on 18 Dec 2003:

          DG> The columnClasses attribute doesn't work for tables that add or
          DG> remove columns. I suggest we remove that attribute and add a
          DG> styleClass attribute to <h:column>.

          Hans Bergsten later followed up on 22 Jan 2004:

          HB> I'm going through my mailbox and found this old suggestion from
          HB> David, and I can't see that it was discussed at all.

          HB> It may be too late, but maybe we can consider this a bug and still fix
          HB> it for 1.0. That would also solve a problem reported in the forum:

          HB> <http://forum.java.sun.com/thread.jsp?forum=427&thread=484248>

          HB> With a "styleClass" attribute on <h:column>, the forum issue could
          HB> be handled with a JSF EL expression:

          HB> <h:data_table var="foo" ...>
          HB> <h:column styleClass="#

          {foo.style}

          ">
          HB> ...
          HB> </h:column>
          HB> </h:data_table>

          And later, on 5 Feb 2004

          HB> I guess this one didn't make it (which is too bad), but we must at
          HB> least include that the <h:column> action exists, even if it doesn't
          HB> have any attributes or a renderer.

          HB> A problem with putting all renderer attribute descriptions in a separate
          HB> file is that we don't have any real description of the HTML tag
          HB> library, and actions without a renderer aren't described at all (the
          HB> <h:column> action may be the only one). Maybe section 9.5 should still
          HB> have a subsection per action, but refer to the renderer document for
          HB> details in case the combo is described there.

          So we see that this is something that has simply been dropped.

          Show
          Ed Burns added a comment - Here's the first on this. From Craig McClanahan in 2002: CM> Attribute "columnClasses" - Some renderers support an attribute of CM> this name, which contains a comma-delimited list of CSS style CM> classes that will be used in sequence. If a rendered table has more CM> columns than the number of class names in this list, it will be CM> restarted from the beginning as many times as needed. However, the CM> first column in a new row will always be rendered with the first CM> class listed here. But then, interestingly, David Geary says, on 18 Dec 2003: DG> The columnClasses attribute doesn't work for tables that add or DG> remove columns. I suggest we remove that attribute and add a DG> styleClass attribute to <h:column>. Hans Bergsten later followed up on 22 Jan 2004: HB> I'm going through my mailbox and found this old suggestion from HB> David, and I can't see that it was discussed at all. HB> It may be too late, but maybe we can consider this a bug and still fix HB> it for 1.0. That would also solve a problem reported in the forum: HB> < http://forum.java.sun.com/thread.jsp?forum=427&thread=484248 > HB> With a "styleClass" attribute on <h:column>, the forum issue could HB> be handled with a JSF EL expression: HB> <h:data_table var="foo" ...> HB> <h:column styleClass="# {foo.style} "> HB> ... HB> </h:column> HB> </h:data_table> And later, on 5 Feb 2004 HB> I guess this one didn't make it (which is too bad), but we must at HB> least include that the <h:column> action exists, even if it doesn't HB> have any attributes or a renderer. HB> A problem with putting all renderer attribute descriptions in a separate HB> file is that we don't have any real description of the HTML tag HB> library, and actions without a renderer aren't described at all (the HB> <h:column> action may be the only one). Maybe section 9.5 should still HB> have a subsection per action, but refer to the renderer document for HB> details in case the combo is described there. So we see that this is something that has simply been dropped.
          Hide
          Ed Burns added a comment -

          cat2

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

          renderkit

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

          These are targeted at 2.1.

          Show
          Ed Burns added a comment - These are targeted at 2.1.
          Hide
          Ed Burns added a comment -

          triage

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

          rogerk

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

          triage

          Show
          rogerk added a comment - triage
          Hide
          rogerk added a comment -

          triage

          Show
          rogerk added a comment - triage
          Hide
          lu4242 added a comment -

          This issue has been reported recently on stackoverflow:

          http://stackoverflow.com/questions/21555952/myfaces-datatable-columnclasses-strange-behaviour

          It shows that the behavior of columnClasses is not intuitive. Since we cannot really change columnClasses without break some existing code, JAVASERVERFACES_SPEC_PUBLIC-217 should be fixed.

          Show
          lu4242 added a comment - This issue has been reported recently on stackoverflow: http://stackoverflow.com/questions/21555952/myfaces-datatable-columnclasses-strange-behaviour It shows that the behavior of columnClasses is not intuitive. Since we cannot really change columnClasses without break some existing code, JAVASERVERFACES_SPEC_PUBLIC-217 should be fixed.
          Hide
          Ed Burns added a comment -

          Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

          Show
          Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
          Hide
          Manfred Riem added a comment -

          Setting priority to Minor

          Show
          Manfred Riem added a comment - Setting priority to Minor

            People

            • Assignee:
              Unassigned
              Reporter:
              frankwhofmann
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: