Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-8930

layoutManager.rowCssClasses are cleared within the TableLayoutManager - add new implementation for row css

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-4181Add clear cache method to KeyValuesFinder interface and base class
      KULRICE-9215Multi row col span overwritten in TableLayoutManager
      KULRICE-9587Add new button css classes to UIF
      KULRICE-7716Update Lightboxes to allow for Maintenance Documents within them
      KULRICE-10761Fix layout in KRAD Library Css Grid Layout Row Css
      KULRICE-5181DataTable should skip add row during column sorting
      KULRICE-10048row css does not move with collection items on sort when CollectionGroup.useServerPaging=true
      KULRICE-7430Collection with in subcollection - Add row should not be added to the collection if it has errors
      KULRICE-7603Add Blank Line and Add Via Lightbox for Table Layouts not highlighting new row
      KULRICE-5437UIF Framework - Add standard markup for table semantics
    • Rice Module:
      KRAD
    • Application Requirement:
      KS, KS My Plan
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      When setting the layoutManager.rowCssClasses property, I found my classes were not being added. Discovered in the TableLayoutManager the line:

      getRowCssClasses().clear();

      which removes any values defined.

      Would like to have the ability to have different css classes based on a property within the dataobject so rows can have different styles based on data.

        Activity

        Hide
        Larry Symms added a comment -

        From Mark Fyffe:

        I have resolved the client-side delays we've been experiencing on the application side. In UW's My Plan code, there are onDocumentReadyScript defined in collection items used to assign CSS classes to table rows, for example:

        <property name="onDocumentReadyScript" value="
        var row = jQuery('#@

        {#line.atpId.replace('.','-')}

        -@

        {#line.registrationCode}

        ').parents('tr');
        row.addClass('row');
        if (@

        {#line.primary}

        ) {
        row.addClass('primary');
        if (@

        {#line.planItemId NE null}

        ) row.addClass('myplan-section-planned');
        if (@

        {#line.stateKey NE 'kuali.lui.activity.offering.state.offered'}

        ) row.addClass('fl-text-lightgray');
        "/>

        In these tables, there are three rows per collection line, so in our severe test case over 1000 executions of jQuery('#cellId').parents('tr'). This is a bit much for the browser to handle. In KSAP I've removed these scripts, and added layout manager code to assign CSS classes to the table rows at rendering time. The one other purpose of these scripts, to hide some rows, has been consolidated to a single selector within onDocumentReadyScript on the table collection.

        After replacing these scripts with server-side rendering logic, the client-side delay in our test case came down to roughly 5 seconds, all contained within the call below - the delay is now essentially only the time it takes for the browser to render the tables.

        // replace component
        if (jQuery("#" + id).length)

        { jQuery("#" + id).replaceWith(component); }

        I have tried rendering both with and without forceLocalJsonData, with no appreciable difference in performance.

        Regarding LightTable, our table in question has 1 or 3 rows and a variable number of columns per line depending on the item, and relies on multiple row and colspan definitions to handle formatting. LightTable builds an aaData structure for the jQuery DataTables plugin; while DataTables is a good fit for presenting data in an actual table, it is not entirely suitable for table-based layout with varying numbers of columns/rows per item. I may be missing something, but it would appear that LightTable is not a good fit for this purpose after all - I might argue, in fact, that a table at all may not be a good fit for this particular page element Table or no, the complexity of the collection items would seem to make it a good candidate for rendering via a custom component template. However, we are not currently in a position to discuss drastic changes to the architecture of this page.

        IMO there is really only so much that can be expected from the framework when it comes to rendering complex collections of this size on a single page, no matter what is used to control layout. Even without performance bottlenecks, attempting to display 1000 data elements on a single page in any sort of meaningful way is a simply a challenge! To further address this issue on the IU end I've overridden components to reduce what needs to be displayed to what is most meaningful - in this case, rendering one term's worth of class scheduling data at a time, and displaying no sections at all until a term has been specifically selected by the student, thereby rendering only summary data until further details are requested and cutting the volume of detail data rendered to 1/4 to 1/3 its original size while making what is immediately visible more meaningful to the user.

        Our rending time for this page is now roughly 3 seconds on the server side, and client-side delays are under 1 second. My updates have been committed to KSAP trunk, under KSAP-40.

        Show
        Larry Symms added a comment - From Mark Fyffe: I have resolved the client-side delays we've been experiencing on the application side. In UW's My Plan code, there are onDocumentReadyScript defined in collection items used to assign CSS classes to table rows, for example: <property name="onDocumentReadyScript" value=" var row = jQuery('#@ {#line.atpId.replace('.','-')} -@ {#line.registrationCode} ').parents('tr'); row.addClass('row'); if (@ {#line.primary} ) { row.addClass('primary'); if (@ {#line.planItemId NE null} ) row.addClass('myplan-section-planned'); if (@ {#line.stateKey NE 'kuali.lui.activity.offering.state.offered'} ) row.addClass('fl-text-lightgray'); "/> In these tables, there are three rows per collection line, so in our severe test case over 1000 executions of jQuery('#cellId').parents('tr'). This is a bit much for the browser to handle. In KSAP I've removed these scripts, and added layout manager code to assign CSS classes to the table rows at rendering time. The one other purpose of these scripts, to hide some rows, has been consolidated to a single selector within onDocumentReadyScript on the table collection. After replacing these scripts with server-side rendering logic, the client-side delay in our test case came down to roughly 5 seconds, all contained within the call below - the delay is now essentially only the time it takes for the browser to render the tables. // replace component if (jQuery("#" + id).length) { jQuery("#" + id).replaceWith(component); } I have tried rendering both with and without forceLocalJsonData, with no appreciable difference in performance. Regarding LightTable, our table in question has 1 or 3 rows and a variable number of columns per line depending on the item, and relies on multiple row and colspan definitions to handle formatting. LightTable builds an aaData structure for the jQuery DataTables plugin; while DataTables is a good fit for presenting data in an actual table, it is not entirely suitable for table-based layout with varying numbers of columns/rows per item. I may be missing something, but it would appear that LightTable is not a good fit for this purpose after all - I might argue, in fact, that a table at all may not be a good fit for this particular page element Table or no, the complexity of the collection items would seem to make it a good candidate for rendering via a custom component template. However, we are not currently in a position to discuss drastic changes to the architecture of this page. IMO there is really only so much that can be expected from the framework when it comes to rendering complex collections of this size on a single page, no matter what is used to control layout. Even without performance bottlenecks, attempting to display 1000 data elements on a single page in any sort of meaningful way is a simply a challenge! To further address this issue on the IU end I've overridden components to reduce what needs to be displayed to what is most meaningful - in this case, rendering one term's worth of class scheduling data at a time, and displaying no sections at all until a term has been specifically selected by the student, thereby rendering only summary data until further details are requested and cutting the volume of detail data rendered to 1/4 to 1/3 its original size while making what is immediately visible more meaningful to the user. Our rending time for this page is now roughly 3 seconds on the server side, and client-side delays are under 1 second. My updates have been committed to KSAP trunk, under KSAP-40 .
        Hide
        Jerry Neal (Inactive) added a comment -

        Brian and I were discussing reworking how rowCssClasses work on table layout manager. Right now you have to specify an index which is not very useful for dynamic collections.

        Proposal is to allow use of expressions (that can look at the line) and return classes for the row. In addition we would provide variables like evenRow and oddRow for use in the expression.

        Show
        Jerry Neal (Inactive) added a comment - Brian and I were discussing reworking how rowCssClasses work on table layout manager. Right now you have to specify an index which is not very useful for dynamic collections. Proposal is to allow use of expressions (that can look at the line) and return classes for the row. In addition we would provide variables like evenRow and oddRow for use in the expression.
        Hide
        Brian Smith (Inactive) added a comment - - edited

        This is now completely redone for 2.3. Use conditionalRowCssClasses for row styling needs, do not set rowCssClasses.

        Show
        Brian Smith (Inactive) added a comment - - edited This is now completely redone for 2.3. Use conditionalRowCssClasses for row styling needs, do not set rowCssClasses.

          People

          • Assignee:
            Brian Smith (Inactive)
            Reporter:
            Garett Gowens
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel