Announcement

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

    12.0p Issue with ListGrid exportData() and not used fetch operationId

    Hi Isomorphic,

    I noticed an issue with ListGrid.exportData().
    It does not use take the ListGrid's fetch operationId in the export request. To me, this seems as important as the ListGrid's criteria, which are in the request as expected.
    Please see this modified example, where you can see that the initial fetch uses fetchFooBar, while the export click (keep format at "CSV") does not.

    If one would use the commented out // fetchOperation: "fetchFooBar", it would be possible to add this again manually in the export's requestProperties via countryList.fetchOperation, but not in the case where the operationId comes from the fetchData-call with parameters.

    IMHO in both cases the operationId fetchFooBar should automatically be part of the export-request.

    Please see this modified sample (v12.0p_2020-04-12):
    Code:
    isc.ListGrid.create({
        ID: "countryList",
        width:500, height:250, top:70, alternateRecordStyles:true,
        dataSource: worldDSExport,
        // [B]fetchOperation: "fetchFooBar", // try with with instead of a fetchData() parameter as well[/B]
        autoFetchData: false,
        fields:[
            {name:"countryName", title:"Country"},
            {name:"capital", title:"Capital"},
            {name:"continent", title:"Continent"},
            {name:"independence", title:"Nationhood", width:100},
            {name:"population", title:"Population"}
        ],
        showFilterEditor: true,
        implicitCriteria: { _constructor: "AdvancedCriteria", operator: "and",
            criteria: [
                { fieldName: "countryName", operator: "iEndsWith", value: "land" },
                { fieldName: "capital", operator: "iBetweenInclusive", start: "A", end: "FZZZZZZZZZZ" },
            ]
        }
    });
    [B]countryList.fetchData({continent:'Europe'}, null, {operationId: "fetchFooBar"});[/B]
    
    isc.DynamicForm.create({
        ID: "exportForm",
        width:300,
        fields: [
            { name: "exportType", title: "Export Type", type:"select", width:"*",
                defaultToFirstOption: true,
                valueMap: { 
                    "csv" : "CSV" , 
                    "xml" : "XML", 
                    "json" : "JSON",
                    "xls" : "XLS (Excel97)",
                    "ooxml" : "OOXML (Excel2007)"
                }
            },
            { name: "showInWindow", title: "Show in Window", type: "boolean", align:"left" }
        ]
    });
    
    isc.Button.create({
       ID: "exportButton",
       title: "Export",
       left: 320,
       click: function () {
           var exportAs = exportForm.getField("exportType").getValue();
           var showInWindow = exportForm.getField("showInWindow").getValue();
           if (exportAs == "json") {
               // JSON exports are server-side only, so use the OperationBinding on the DataSource
               countryList.exportData({ operationId: "customJSONExport", 
                   exportDisplay: showInWindow ? "window" : "download"});
           } else {
               // exportAs is not JSON, so we can set that with requestProperties
               countryList.exportData({ exportAs: exportAs,
                   exportDisplay: showInWindow ? "window" : "download"
               });
           }
       }
    });
    Best regards
    Blama

    #2
    Hi Isomorphic,

    in both cases countryList.data.fetchOperation gives the same result in the Developer Console's evaluate box.
    I think this is the data that should be used for the default export-fetch.

    Best regards
    Blama

    Comment


      #3
      Hi Isomorphic,

      did you already have a look at this one?

      Thank you & Best regards
      Blama

      Comment


        #4
        Hi Isomorphic,

        this one seems to have been addressed, as per Change Log information for "export" via the new attribute DataBoundComponent.exportOperation, which is in 12.0p and 12.1p.

        It's great this is addressed, but regarding the change log itself this issue here still applies.

        Thank you & Best reagards
        Blama

        Comment

        Working...
        X