Making Better Catalog UI Macros

Many of us would have played around with UI Macros before. They’re a very useful part of the system and they allow for all manners of customisations to the tool. This post is focussed on UI Macros on catalog items as this is where I generally use them the most, to make form submission easier.

One thing that you probably would have noticed is that you can’t use standard g_form methods on the UI macro to hide it, make it mandatory etc. nor can you use UI Policies. You can create custom client scripts to find the elements and hide/show them etc but this can be a bit annoying so I dug a little deeper to understand why and how to get them working. Low and behold, I found a VERY easy way to get them working!

Just add the name of the UI macro as the ‘name’ and ‘id’ of the field you want to manipulate!

For example, to create a text variable you can use:

<input id="$[jvar_question_name]" style="width:50%" name="$[jvar_question_name]" value="" class="cat_item_option questionsettext"/>

With this simple fix you can now use g_form against the field as you normally would by calling the variable/field name or UI policies to modify this field.

Also, as a nice little plus, this little amendment will also cause the value of this field to be stored in the question_answer table for viewing on the variable editor later. RESULT!

So how does this work? Well, the jvar_question_name stores the actual name of the variable. The actual name is in the form of IO:sys_id (or ni.io:sys_id when on a variable editor). You’ll see this name when going into the client script table and viewing an ‘on change’ script from the list view. If you look at the field name you’ll see this value. This name is called the variables ‘real name’. The name that we access the field by using g_form, is called the ‘pretty name’ (I didn’t make these up).

The idea of the pretty name is that it’s a lot easier for us to remember and makes our code a lot easier to read and maintain. When the form is loaded, an object is created which maps the pretty names to the real names of the variables. Whenever we use g_form, the first thing it does is goes through this object to match this pretty name to the real name. If you want to give this a go, press ctrl+alt+shift+j and try the following script :

alert(g_form.resolveNameMap('yourvariable'));

As with any object property, you can read this function to see what I’ve said above by running this code:

alert(g_form.resolveNameMap);

The best part for me with this is the storing of the value in the question_answer table (for record producers) or sc_item_option table (for service requests). This allows for complicated UI Macros to be created, with multiple input fields, to be stored and read back later on. I’ll hopefully show you a complete example of this soon. Watch this space…

But in the mean time, this simple little change will immediately make your UI Macros work better. Hopefully you find this as useful as I did!

5 Comments

  1. You are a legend, thanks for this!
    I ended up making a ui macro which I use on a catalog item to show a html annotation. I use your code in the macro to get the “variable” – question record (item_option_new) – and read the “default_html_value” from it and render that in the macro. That means I have 1 macro but can use it across all my catalog items.
    var gr = new GlideRecord(‘item_option_new’);
    gr.get(jelly.jvar_question_id);
    gr
    ${gr.default_html_value}

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s