Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    New 13.1d feature feedback/question: ListGrid.getRowRangeDisplay()

    Hello Isomorphic,

    looking at the 13.1d docs I noticed the new ListGrid.getRowRangeDisplay() and was wondering how to use this.
    I tried it here (SNAPSHOT_v13.1d_2024-05-28) with this code, but apparently this is not correct:
    Code:
    isc.ListGrid.create({
        ID:"dsListGrid",
        width: "100%",
        height: "100%",
        autoFetchData: true,
        dataSource: "supplyItem",
        gridComponents : ["filterEditor", "header", "body", "summaryRow", "rowRangeDisplay"],
        rowRangeDisplayStyle:"full"
    });
    I assume this is to have the label from this sample out of the box without any code. If so, this is of course great.

    Could you add a sample using rowRangeDisplay and also the new rowCountStatus, which I think is related?

    Best regards
    Blama

    #2
    This overview should clear it up:

    https://smartclient.com/smartclient-...owRangeDisplay

    We would like to make it available as a part of gridComponents, but really what you want is a full toolbar with many built-ins (like an export button, etc) which we will add later. For now, the grid will create the rowRangeDisplay for you if you ask, but you can't just declare it.

    Comment


      #3
      Hi Isomorphic,

      that sounds great. I built something like this (buttons, not the row count) myself (see screenshot).
      If that would be possible out of the box this would be great!

      If I can suggest controls to choose from (so they are there if added/activated and not there if not):
      • Buttons:
        • Expand/Close all groups (stateful?)
        • Show/Hide filterRow (stateful)
        • Reload
        • InvalidateCache
        • ExportClientData
        • ExportData
      • searchForm
      • Row count
      • Further controls
      As the buttons are pretty basic perhaps just the possibility to add buttons is enough, but of course it is nicer if one just has to just flip a setter.
      Of course it would be even better if all of these were configurable autoChildren.

      I added my controls to a SectionStackSection. Perhaps it is an idea to make this possible as well, as otherwise the SectionStackSection wastes a lot of vertical screen real estate.

      Best regards
      Blama

      Click image for larger version  Name:	ListGrid.PNG Views:	0 Size:	16.7 KB ID:	272453

      Comment


        #4
        This is roughly what we have in mind except there are something like 30 different controls you might want, especially considering variants (like wanting a simple export button for one format vs wanting a dropdown, etc).

        As you say, we want them to be both declaratively configurable and also able to be programmatically accessed so you can put them into a SectionStack or other header that already exists for the grid.

        The primary problem is arguably that the grid API is already so huge, that we don't want to add 30 more autoChildren (hundreds of APIs!).

        Comment


          #5
          Hi Isomorphic,

          that would be great. Apart from some ListGridConfig-Helper class that you assign to a ListGrid I don't have an idea either.

          On the other hand the ListGrid-docs is currently already at 143 A4 pages with 23 pages of index (don't worry, no tree had to die to find out these numbers ;).
          So perhaps it does not matter that much as the API can be used with search only already now. And at least the SmartClient Reference Docs are super easy to use and search. SmartGWT is a bit more difficult, but perhaps you can point out in the SmartGWT docs that also SmartGWT developers can (should?) use the SmartClient Reference Docs. Once you found your SmartClient property/method it is easy to find the respective SmartGWT getters/setters.

          Best regards
          Blama

          Comment


            #6
            Hi Isomorphic,

            another idea, no idea if it is feasible. Both the SmartClient Reference docs and SmartGWT itself (and then the JavaDoc for SmartGWT) must already be generated automatically from the SmartClient sources.
            How about a Reference docs application for SmartGWT, also generated from these sources?

            Best regards
            Blama

            Comment

            Working...
            X