This JavaScript object is what allows us to pass that precious data into a client script. The primary, and only, use for this that I have found so far is to make additional information to client scripts. A Display Business Rule is the colloquial name for having the server execute some code for us every time a user displays a particular form. It’s the last item in that list that we are focused on today. Asynchronously (at some point in the future after the record is saved, but not immediately).Display Business RulesĪs you likely know, each Business Rule can be told when it should run: While there are a handful of different architectural principles we can apply to reduce the number of “round trips” to the server, one of the more recent and most powerful additions is the combination of Display Business Rules and the g_scratchpad JavaScript object. It’ll seem to your users that they’re constantly waiting on a “laggy” system to do one thing or another. While all three of these can be used asynchronously, it’s still going to drag down the perceived User Experience if you have too many asynchronous actions running on a form. This includes GlideRecord, GlideAjax, and getReference(). What’s the Problem?Īs we recently discussed, the ACE Report, is very slanted against any synchronous use of functions that gather information from the server. If you’re not clear on the differences between the client and server and how interaction between the two affects the User Experience, head one post over and read my explanation, and then come back: Client vs. Let’s explore one method of eliminating the need for such occurrences. One of the core principles to maintain optimal performance in ServiceNow is: Minimize round trip server calls from client scripts. Home › Developers › Bite #14: Display Business Rules & g_scratchpadīite #14: Display Business Rules & g_scratchpad
0 Comments
Leave a Reply. |