• Replies 2 replies
  • Subscribers 0 subscribers
  • Views 13 views
  • Users 0 members are here
Options
3sides - Social sharing widget
Related

ExportXML uses last iSheet search, limiting data pulled

Peter Darling
27232

I'm using the ExportXML method + Javascript to display/process some isheet data on a HighQ homepage, as I think a lot of people on here do . I've noticed is that the export URL/method ("./sheetViewExportXML.action?metaData.siteID=xxxx"&metaData.sheetId=xxxx&metaData.sheetViewID=xxxx &metaData.isheetExportType=xml")  seems to remember the last search made on the iSheet, exporting only the data that satisfies the last search (even if the window/tab with the search results is closed), resulting in incomplete data being pulled by the Javascript code. For example, let's say a homepage uses the above method + jquery to display every value of an iSheet column. The user views the homepage and sees all records from the iSheet in the content panel; if they then go to that iSheet, do a search, then go back to the homepage, they will then only see the values of records that satisfy that search on the homepage.

Other than manually going back into the iSheet to clear the search, is there any way to ensure that the complete iSheet data is grabbed with the ExportXML? Even searching in a different view than the one in the "viewID" parameter affects the data pulled by the ExportXML. 

The current (extremely clunky, kind of slow, and, at least in firefox, kind of buggy) workaround I'm playing with is putting the entire iSheet in a 0x0 iframe in the same panel as my javascript, waiting for that to load before attempting to grab the data. I've seen some people on here requesting the ability to use search parameters with the ExportXML URL, which would also be helpful, but is there anyway to "reset" or ignore the search state of the isheet when calling ExportXML, or is that baked into the function?

I'm wondering if anyone else has run into this, and if there's any solution, or a workaround more elegant than mine.

Thanks!

Parents

  • Peter Darling , firstly I would say that ultimately you are heading into a functional cul-de-sac, as the ExportXML does have limitations, some that you've highlighted, and that long-term goal should be to use the Collaborate (iSheet) API's from within Collaborate - I believe that is what most here have eventually headed to, once having used the ExportXML functionality.

    That being said, another way to achieve what you want without using an iframe is to programatically 'clear' the search context using the (Collaborate-native) "renderXML" endpoint.

    Given the code attached, we can use our function to ultimately call the export endpoint, via a "render reset", e.g.

    CommunityExamples.exportSheetXML({ 
   siteId: 9999,
   sheetId: 9999,
   sheetViewId: 9999
}).then(console.log)    
I've commented the code, however, the key is to call the "renderXML" prior to our "exportXML" call, stating it's NOT an advanced search (false) leading to any current (user) search context being reset. And so as to not cause too much performance overhead, we ask for an iSheet item that will never exists - hopefully this ultimately results in a SQL query on a primary key, which should limit performance for this "additional" pre-query.

     

    Obviously using the renderXML endpoint introduces a risk as Collaborate developers could modify it's behaviour at any point, and so would need to be tested regularly, though it rarely does in the scale of years. Check the comments in this post for some context.

    Andrew

Reply

  • Peter Darling , firstly I would say that ultimately you are heading into a functional cul-de-sac, as the ExportXML does have limitations, some that you've highlighted, and that long-term goal should be to use the Collaborate (iSheet) API's from within Collaborate - I believe that is what most here have eventually headed to, once having used the ExportXML functionality.

    That being said, another way to achieve what you want without using an iframe is to programatically 'clear' the search context using the (Collaborate-native) "renderXML" endpoint.

    Given the code attached, we can use our function to ultimately call the export endpoint, via a "render reset", e.g.

    CommunityExamples.exportSheetXML({ 
   siteId: 9999,
   sheetId: 9999,
   sheetViewId: 9999
}).then(console.log)    
I've commented the code, however, the key is to call the "renderXML" prior to our "exportXML" call, stating it's NOT an advanced search (false) leading to any current (user) search context being reset. And so as to not cause too much performance overhead, we ask for an iSheet item that will never exists - hopefully this ultimately results in a SQL query on a primary key, which should limit performance for this "additional" pre-query.

     

    Obviously using the renderXML endpoint introduces a risk as Collaborate developers could modify it's behaviour at any point, and so would need to be tested regularly, though it rarely does in the scale of years. Check the comments in this post for some context.

    Andrew

Children
No Data