Service Portal, caching form state - what are best practices?

[Craig Jacobs]

Hello Community. I'm curious about best practices for storing state when implementing a Service Portal page. I re-hosted a Catalog Item form on the Service Portal. Previously, I used two variables on the form to store state, I made them invisible with a UI Policy. Since the move to the SP, I had to implement an Ajax class to fetch data which I would like to cache so I don't have to fetch it again. What's the best way to do this?

Thank you,

Craig

[Ravi9]

do i assume its a static data that you have to read every time using ajax ? did u consider widget instance option already ? image below for reference

[Craig Jacobs]

Hi Ravi, thank you for the answer. I'm not using a widget, I'm rehosting a Service Catalog Item on the Service Portal. Now, because getXMLWait() is no longer supported (which seems like a bad decision), I'm using an async onSubmit handler. In order to do this, I have to cache the state of a request on the server side using  gs.getSession().putClientData('isOrderProcessed', true), then, on the client (where I can only read data), I have var isOrderProcessed = g_user.getClientData('isOrderProcessed'); where I return true if isOrderProcessed is true. Then, call another server-side function to clear isOrderProcessed. I guess there used to be a g_user.setClientData() but that has also, apparently, been deprecated.

I understand the desire to decouple the client from the server using async processes, but in some cases, the advantages of async come at the price of vastly more complicated code while doing very little to improve the user's experience. 

I'd be interested in what the community thinks about this.