Announcement

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

  • HowTo: Load all remaining ListGrid rows on demand

    Hi Isomorphic,

    I'm displaying a ListGrid in current 5.0p where the User can do a exportClientData(). As the ListGrid itself is very efficient with not loading too much data, the user wont have all data available normally.
    I can detect this not fully loaded data via lg.getResultSet().getLength() and lg.getResultSet().getAllCachedRows().getLength() and ask the user how to proceed if the data is not fully loaded.

    If he or she decides for loading all data prior to exporting, how is this "fetch the remaining rows" best done?

    Thank you & Best regards
    Blama

  • #2
    Just call resultSet.getRange(0, resultSet.getLength()).

    Comment


    • #3
      That was fast, thank you!

      Comment


      • #4
        Hi Isomorphic,

        resultSet().getRange() does not have a CallBack-override, but I need to wait until the data arrived before I can start the export. How is this best done?
        I could use a fetch with extra DSRequest with setStartRow(0) and setEndRow(resultSet.getLength()), but is this really the solution?

        Out of interest: Would resultSet().getRange() recognize that it already has let's say rows 0-75 and start from 76 then?

        Best regards
        Blama

        Comment


        • #5
          If you need to wait for data to arrive, use the DataArrived event.

          Yes, getRange() starting from 0 will avoid a duplicate fetch for a contiguous range of already-loaded rows starting from the 0 index.

          Comment


          • #6
            Hi Isomorphic,

            I did as suggested and it works. Thanks a lot and once again: Impressive!

            This is my code:
            Code:
                        if (fetchAllBeforeExport) {
                            ResultSet resultSet = exportListGrid.getResultSet();
                            myHandler = resultSet.addDataArrivedHandler(new DataArrivedHandler() {
                                @Override
                                public void onDataArrived(DataArrivedEvent event) {
                                    exportListGrid.exportClientData(exportRequest);
                                    myHandler.removeHandler();
                                }
                            });
                            resultSet.getRange(0, resultSet.getLength());
                        } else {
                            exportListGrid.exportClientData(exportRequest);
                        }
            The only think I'm not sure about is the myHandler.removeHandler(). I have it because I do not want the export to be started everytime the ListGrid/ResultSet gets new data.
            I think that it leads to this message in the Developer Console, though (v10.0p_2015-10-23):
            Code:
            01:44:36.719:MUP6:WARN:Selection:ListGrid_export_selection:Observation error caught in ignore(): Method dataArrived was being observed on object [ResultSet ID:isc_ResultSet_1 (dataSource: V_LEAD_EXPORT, created by: ListGrid_export)] but the function appears to have been directly overridden. This may lead to unexpected behavior - to avoid seeing this message in the future, ensure the addMethods() or addProperties() API is used to modify methods on live SmartClient instances, rather than simply reassigning the method name to a new function instance.
            01:44:36.904:MUP6:INFO:ResultSet:ListGrid_export:Creating new isc.ResultSet for operation 'V_LEAD_EXPORT_fetch' with filterValues: {
                "fieldName":"CREATED_BY", 
                "operator":"equals", 
                "value":1288, 
                "_constructor":"AdvancedCriteria"
            }
            How is such a handler removed and is it necessary to remove it?

            Best regards
            Blama

            Comment


            • #7
              This is an artifact of some internal details it would take a while to explain, and is harmless. If you are concerned about the warning, instead of removing the handler, just set a flag that causes it not to take action when it shouldn't.

              Comment


              • #8
                Is there a limit for how many rows it is possible to export this way? I am doing it the same way as Blama above here, and I have problems with exporting 3300 rows. When I limit it to the half it works. I get no error, but it seems that the transaction never ends?

                I have used the exportData() method before with over 3000 rows, and that went well, but I want to use exportClientData() to get the formatting from the client side into excel.

                Comment


                • #9
                  You could grab the data from the ListGrid, put a subset of it in a new RecordList and apply it to the same ListGrid via setData() before exporting, then switch back to the original dataset.

                  Comment


                  • #10
                    Hi anderfim,

                    I still have this code in production, but most likely I'm going to change to exportData() at some point, because it is really slow for me for approx the 3000 rows you mention.
                    I don't know if it has to be and I'm doing something wrong (I would have asked that before trying to move to exportData()), but for me in a "normal ListGrid" (approx 15 columns, 1-2 Hilites) it is too slow to be worth the value of nicely formatted data.
                    At least I'm going to let the user choose.

                    The error you are getting is most likely some kind of browser timeout, perhaps have a look with the F12 tools when doing the export.

                    Best regards
                    Blama

                    Comment


                    • #11
                      Thank you for quick and good response, both admin and Blama, I will give it a try and update you :)

                      Best regards
                      Anders

                      Comment


                      • #12
                        The problem I faced was related to this forum post that you Blama has replyed to as well: https://forums.smartclient.com/forum...ceeded-warning

                        I set the maxPostSize="-1" in tomcat server config, and now I get all the rows. Do you think this is good enough, or would it be cleaner to do it like admin suggest above?

                        Best regards
                        Anders

                        Comment


                        • #13
                          Hi anderfim,

                          I think Isomorphic is talking about a solution if you do not want to export the whole 3300 rows, but only a part of it.
                          As I understood, you do want to export the whole dataset, but had problems with the maxPostSize issue, which is now solved.

                          I don't know how long your 3300 rows export takes (but would be interested in that number), but would do the following:
                          Measure time it takes for you per record. Think what you are willing to accept as max time. See the data size for that export. Set maxPostSize to that value plus some safety margin.

                          In you client code, depending on totalRows show some dialogs if export will take longer than some threshold x from your estimations
                          • Ask for "export only current dataset"
                          • If true, just export, if false
                            • compute from your numbers if the total dataset will exceed maxPostSize
                              • if true, do exportData()
                              • if false ask user for if expected time for "export total" is OK for the user
                                • If true, fetch remaining data, then export
                                • if false, offer to export as unformatted via exportData()

                          My current code does part of that, but IMHO this is what a perfect export would look like.

                          Best regards
                          Blama




                          Comment

                          Working...
                          X