specification for PTAEO validation

This SNART requirement # 51 for the work against WSDL, and requirement # 50 for packaging up PTAEO into a module that can be easily dropped into each catalog item that needs PTAEO.

PTAEO is an acronym for

project
task
award
expenditure
organization

In START, this was modeled as five input boxes, with formatting that enforced the width of the data input.

In ServiceNow, it's not so easy to directly mimic this behavior. I've seen a grand total of ONE demo service catalog with multiple items on a single horizontal line, and that was using Berlin. I suspect they had to do a CSS hack to make it work, and I've thrown hours at this fruitlessly in the past.

So far, we have modeled the PTAEO input as a single box with dots separating the values for the fields.

The next phase is to submit the PTAEO to the webmethods PTAEO validator. Bill is working on doing a quick demo / mockup of the variables we can send to the WSDL via the mid-server.

What

Next we need to either silently accept the value, or perhaps provide a visual cue that the value is accepted. Perhaps turn the field green.

If the the value is bad, we need to provide some form of notification of the mistake. This functionality is already built-into the webmethods WSDL; it's passed along as a text error message. The simplest notification would be a popup with the content of the WSDL complaint passed-through. Nicer would be some color or syntax highlighting.

When

I envision this validation to be controlled by Client Scripts. I think that onChange we should fire the validator. If we try it and it seems dumb, we can try a different tack.

We definitely need to validate onSubmit, and we should prevent/interrupt the submit from completing if the data is denied.

How

Through trial and error I learned that you can only talk to the PTAEO via Script Includes and Background Scripts, but not directly from Client Scripts.

However, you may be able to invoke the Script Includes from a Client Script.

Making things messier, you cannot XMLParse with XMLDocument in a Background Script; XML parsing only in a Client Script. Uggggh.

So I'm envisioning a Script Include I have to invoke from a client script, passing it arguments somehow, and then getting back an XML hunk that I have to parse in a client script.

How, round two

I've been working on the scripting. I had a working Background Script. Turned it into a Script Include. Then made a Client Script, using ClientAjax to invoke the Script Include with arguments. So far, it seems that the Client Script isn't successfully contacting the Script Include; something is going wrong with the communications.

There is a sample Hello World script that demonstrates the fundamentals of argument and return value handoff. I should try to make that work, and if it does, I should gradually build on that communications framework to see if I can isolate the problem.