Form validation, pre-defined answers, default values and field refreshing. Can I control how/when this occurs?

[qc4vmware]

I have asked this before and not gotten satisfactory answers.  When launching a workflow interactively I am struggling with an efficient way to load default values and predefined answers programmatically.  How and when those actions get evaluated are a bit of a mystery to me.  It seems like it occurs with every key press in a field.  I am trying to build a fairly complex form that needs to be dynamic in nature.  The default values and valid answers will vary based upon some questions the user answers.  The answers the user provides are sent off to an external api and I get back the information I need to populate these values.  The form is basically unusable as a storm of actions is invoked anytime I put in a keystroke.  Judging buy what I see in the logs it seems like these calls to the actions are actually happening way too many times anyway but if I could somehow at least have them only trigger when the cursor leaves a field or extending the time between keystrokes that the vCO client waits before starting its cycle of executing the field refreshing I could probably work with that.

In the past I have used the web views as a crutch to get around some of this since you need to manually refresh some things when on a single screen and other executions seem to be on hold until you move from screen to screen so with some careful placement of things you can get pretty decent performance.  I can't seem to achieve the same effect in the full client.  We are trying to avoid the web views at this point since they are eol and the target audience for most of what we do are admin folk.  It also makes developing these intelligent forms painfully difficult and I find myself creating another wrapper workflow devoid of any of the smarts so I can quickly execute them for test purposes.

Before anyone suggests that I need to double check my actions and make sure they aren't doing any unnecessary processing trust me they all return immediately if that is an option.  Its things like requiring a host name be entered or some other long string.  In this case a unique id for lookup that is killing things.  There is no real way within the action to know if what is being entered is complete.

[cdecanini_]

Some of the things that can be done:

- Checking on null input and returning null (first line of your actions) - you seem to do this already

- Use OGNL for not starting the actions : for example evaluating that 3 inputs are already set before calculating the value of a 4th one which itself may be evaluated by other actions

- Lately I experienced that adding the multiline properties is not triggering a change on each char typed.

- Another one is to use composite types as inputs. They get validated only once you submit it

From what I could read some of the action execution can be removed at the vCO level and vCAC 6.2 consumes vRO 6.0 via the RESt API in a way making less actions been started. It is not the case in the "fat" client.

Definitely an annoyance. One improvement I wanted to ask for is that before a field depending on other is calculated the validation of all the depending fields is checked once: no need to calculate depending fields when there are invalid inputs.

[qc4vmware]

Thanks.  I will give the multiline entry a shot for fun.  That might put a bandaid on this particular form I am working.  I just feel like I end up jumping through hoops anytime I want to do anything interesting in the forms... *sigh*.  Today when I was trying to track just when the recalculation of the forms was getting set off I noticed in even the most simple setup (just one field with a data binding) hitting a single keystroke always generated 2 executions of the action assigned to the binding.  Is there any detailed information you can point me to that explains when these get triggered?  In this field I was typing in a FQDN of a host.  Roughly 20 characters which yielded 40 executions of the action.  Each time the action runs it takes around 10 seconds.  I've seen similar anomalies with custom validation on fields.  Maybe they aren't anomalies but seems like bugs or bad design.  I am pretty sure I opened up feature requests to get some of this behavior modified a while back but obviously it has fallen in the low priority bin.

Using vCAC as a front end might also alleviate some of the glitches I am running into but what about customers not using that product?  I certainly don't want to be developing the workflows in the fat client then hopping off into vCAC to run my tests (although I did just that with the web views).  It seems like it should be such an easy tweak but maybe not.

Anyway that is a long winded thanks.  I really do appreciate the tips/tricks.

Paul

[qc4vmware]

Heh... looks like the multi-line is indeed not being evaluated until I exit the field!  Not the prettiest way around the problem but it'll do for now.

[iiliev]

At the moment, there is no way for users to fine tune when/how the presentation form events are triggered, and I don't think there is a detailed documentation about them. It is something too implementation-specific.

I agree that the client UI may become almost unusable if a large number of action invocations are performed but I'm not aware of any immediate plans to change this behavior. vCO Java Client was never intended to be used as an end-user portal (it is positioned more as a dev tool for workflow/content creators) so its performance has never been top priority.

[qc4vmware]

Well like I said it is painful even in development mode and a lot of what we create are administrative automations that are often interacted with from within the client.  Having to go an additional step and create a UI for them aside from the java client is just one more thing to break/maintain.  Its mostly adequate but with just a couple of little tweaks to the performance I'd probably stop complaining.  If I could set per form field evaluations to "leave field" or set an idle keystroke timer for all text fields that would probably take care of most of my belly aching.  For now using the multi-line type seems to be doing the trick.  There is still more executions happening than seems necessary but over all much less lag.

[cdecanini_]

I am working on version 2 of the plug-in generator (using Dynamic Types) and I spent hours to tune the presentation of the workflows since it requires a lot of interactivity doing REST requests / getting results from it.

This is a case where I expect 100% of the end users (the workflow developers) will use this workflow from the java client.

Also all workflow developers do spend a lot of time testing their workflows in the client and waiting for the presentation to load.

Another important aspect is the WYSIWYG aspect of the presentation. Designing a presentation and having discrepencies between the client and vSphere web client / vCAC involve spending a lot more time testing the presentation in the different workflows consumers.

I think vCO has reached quite a level in terms of functionality, that there is no full alternative to the vCO client and that we need to make it more effective / attractive. Besides the presentation there are loads of possible optimizations for example the client is loading / reloading a lot of data from the server, doing costly updates.

[qc4vmware]

Well I'm glad to hear you see the value of improving the fat client performance.  If you can't enact some change I don't know anyone else that could!

While we are on the topic of workflow design.  I don't suppose you have a good example set for interesting things you can do with the OGNL expressions in the workflow presentation.  I only do pretty simple stuff right now and I don't fully understand how vCO parses ognl.  I also can't seem to find any really good documentation on OGNL aside from what apache has which is just confusing for me.  Not being a web developer sort of person its a bit confusing.  I just read through the vCO documentation again and didn't see much of anything enlightening.

[cdecanini_]

I think that in terms of hours spent in vCO client I can brag that I am the number 1 so I can for sure understand other vCO client user pain points. The reason why OGNL may not be documented was that it was supposed to be removed / replaced but I guess that would break a lot of things so it was never done.

For OGNL I do mostly simple evaluations

For example below in a custom validation properties I call an action called setValidation which call a validation action and set the result (in the vCO Dynamic Types cache).

GetAction("com.vmware.coe.presentation","setValidation").call("validateFindRelationUrl",GetAction("com.vmware.coe.dynamicTypes.pluginGenerator.presentation","validateUrl").call( #findRelationUrl ))

And below in a data binding property I use a getvalidation action that read different cache items I set during custom validations and if they are all true I run a REST request action.

GetAction("com.vmware.coe.presentation","getValidation").call("validateRestHost", "validateFindRelationUrl", "validateParentType") ? GetAction("com.vmware.coe.dynamicTypes.pluginGenerator.presentation","executeRequestJsonText").call( #restHost , #defaultMethod , #findRelationUrl , null , #findRelationParam0 , #findRelationParam1 , #findRelationParam2 ) : ""

This way I only run my request action if the other fields are validated and using the cache to set and get the values of the validation remove the action dependencies crippling vCO presentation.

WHile this does improve the presentation I wish there was a vCO client built in feature that say that data binding / default values are not evaluated until all the dependent fields are passing validation.

[qc4vmware]

Wow... I just tried running one of the workflows I have been tweaking in the vSphere web client and the trick of using a multi line entry to get around the crazy stuff that seems to go on with the validations does not hold true there.  In fact the problem is amplified.  Why oh why does no one at VMware work on making this stuff more usable?  Am I missing some trick maybe in the web client where I need to tune something?  Any hidden/secret/tribal knowledge methods of making this better?  At the moment I think I will need to strip all validation to a point after they have clicked go.  This is a pretty lengthy form and it always sucks when you get to the end of one of those and get an error after submittal and have to run the whole form again.