g_scratchpad vs. GlideAjax: is there really a winner?

Mike McCall · ‎05-04-2015

My team is working on a custom application right now, and we needed to decide how to limit which status values are available to users in which situations. We've decided to go with storing the appropriate values in a system property, so we've gone about building our logic from there.

In the form view, we can send the property value right to the client using a Display Business Rule, In the list view, though, we've had to add a Script Include and switch to some GlideAjax: Access property from client script

This leads to a new question: is loading and accessing the g_scratchpad really preferrable to a GlideAjax call, or would it be okay to always stick with GlideAjax?

Since we're forced to use AJAX on list views, it would make for more consistent code to take the same approach on forms (and could also ease troubleshooting in the future if everything is centralized around the shared Script Include). I've typically heard of g_scratchpad as being one step above GlideAjax in best practice world, but is that actually just for the ease of scripting, or does g_scratchpad offer significantly better performance? (Am I forgetting any other arguments for choosing between the two?)

tltoulson · ‎05-04-2015

Hi Michael,

You will most likely be fine with switching to GlideAjax. The g_scratchpad is not always preferable to GlideAjax from a Best Practice standpoint. Each one has its own use case and purpose for which it was designed. You have 3 major costs at play here:

Network Latency

Every GlideAjax call adds an extra network call which takes time.

When it Matters: This matters if retrieving the value prevents the user from interacting with the form in a moment where the user wants to interact with the form (i.e. I can see it but I can't use it) or if it confuses the user by changing the form after the user believes the form to be ready for input ("Where'd that field go!").

Initial Form Load Time

Display Business rules run before a form gets rendered which means any data retrieved at this point costs time between a user clicking something and the form displaying.

When it Matters: This matters if it prevents the user from interacting with the form for an abnormally long time. Usually you won't run into this issue with simple data lookups but it is still worth noting. This is why g_scratchpad is often the "Best Practice".

Maintenance Cost

Why buy one when you can buy two at twice the price, right? Maintaining these scripts, and building them for that matter takes time and effort.

When it Matters: If you find the latency and form load to be negligible, then this factor will probably be the deciding one. It also matters if the maintenance risk is unreasonably high, which probably should not be the case in the current scenario.

So there you have it. Neither one is the best all the time. You have to evaluate your requirements and select the right one for you. Unless you are dealing with a lot of rural users with slow internet, GlideAjax should be fine.

Edit:

A couple other thoughts:

1. Display Business Rules run on every form load. If the data value is not needed on every form load, then the system is wasting resources and time with g_scratchpad

2. GlideAjax is also well suited to use cases where user input is required in order to retrieve the data

View solution in original post

tltoulson · ‎05-05-2015

Great point on traceability, KP!