Integrating UI Pages in Form Sections

[kungfuu72]

I know that you are able to integrate UI Macros into any form section that you create, but can you integrate UI Pages into a form section that you create ?

I am currently developing a custom application in ServiceNow and the current out-of-box form-dictionary field layout is very limiting. I need a very dynamic form for my users to work with.

I know that UI Pages are similar in syntax to UI Macros, but the advantage of using a UI Page is the client script + processing script. If I create a form in a UI Page, I can map the UI Page form values back to the dictionary values for post-processing, but UI Macros do not make this process very convenient like the UI Pages does.

If this is not possible, I might end up making my entire interface my UI Page, but ideally, I'd like to have some dictionary fields visible in the initial section, and my customer UI Page form in another section.

[kungfuu72]

Any thoughts on the possibility of this action?

[James_Neale · Accepted solution]

UI Macros and UI Pages both use the same XML/Jelly/JS syntax with UI Pages making a distinction between HTML, client and processing scripts for ease of use. You can actually just put all of these scripts in the HTML section which I have done many times and it works fine. The main difference is a UI Macro must be included somewhere; you can't post an action to a UI macro on it's own.

The OOB layout might be limiting in some ways but it's designed to be easy to use for non-programmers (personally, I think it's pretty flexible for 95% of the time) and this is the core reason ServiceNow is so powerful. Bear this in mind when considering what you are building, always build everything for the next person. If it is difficult for you to build just imagine how difficult it will be for someone other than you to debug, fix and maintain it. (Been there!)

You might find more help if you can explain what it is that you are trying to do that requires such 'dynamic' capabilities. All of my UI Pages are built because they are not form based. It will be a tool or a specific data view, or based on some other arbitrary idea that doesn't fit the standard record-form model. It sounds like you want the form capabilities but not the form layout - this is something I think might be a stretch too far.

- James

[kungfuu72]

James.Neale

You are exactly correct that I want the form capabilities but not the form layout (previously, I did want this).

Currently I am trying to create an application that a user can utilize to place a task (certain tasks) on a specific schedule for creation. We are calling this schedule, recurring tasks. You choose a task that has already been created and then place it on a schedule using the application. This comes with a new record (the schedule), new number, etc.

If this were just time stamps I think it would be rather easy, but we are also incorporating ordinal dates (such as, the first of every month, the 3rd Monday of October, etc.), and wanted only certain options visible when selecting numerical schedules or ordinal schedules.

Right now I'm utilizing different form sections and hiding/showing based on the recurrence of the schedule chosen (once, daily, weekly, monthly, yearly, etc.). This is totally doable, but there is one issue that I will post next in an other post that is making me 2nd guess the design decision to use the default form layout thus far.

[tltoulson]

Hi James,

Your best avenue on this one is UI Macro's + formatter.   UI Macro's can still make use of client scripts by putting a <script></script> tag in the Jelly script.   This is very powerful and I have used it many times.   Those Macro scripts can even make use of g_form, GlideRecord, and other Client Side scripts available in the rest of the form.   The key to making this work, is to have the Macro client side scripts update Form Fields (hidden ones if necessary).   That way, the 'processing' script is actually replaced by Business Rules and/or On Submit client scripts.

UI Pages are meant to be the page unto themselves.   So while you could embed, possibly via iFrame + macro, it is probably not the best solution.   The UI Macro can achieve the client side scripting and the default form can handle the post processing.

The only way I would use a UI Page in this case is if you intend to completely replace the form with a custom interface.

Kind regards,

Travis Toulson