How much validation is too much validation in the tooling?

[bfitzpat]

As we've been working on migrating the SwitchYard editor over to use the Eclipse DataBinding framework to simplify our lives a bit and offer a more consistent method of interacting with the SwitchYard config model under the covers, we've also been looking at adding field-level validation to the mix. Initially this may be rudimentary, identifying mandatory fields and such, but we're also looking at adding more safeguards to ensure that no wonky data gets into the config.

So here's my question... How much validation is too much validation when we start getting down to the nitty gritty?

Here's a partial list of the validators I see us using:

1) Mandatory fields (i.e. if a field is empty and it's required, don't save until we get something in here)

2) Property substitution (Properties - SwitchYard - Project Documentation Editor) for some fields where identified in the schema (i.e propInteger, etc.)

3) Numeric fields (i.e. unless it's a property substitution, "abc123" is not a valid BigInteger)

4) URI format (i.e. "myuri" isn't valid, but "ftp://foo@myserver?password=secret&ftpClient.dataTimeout=30000" is)

5) Regex (is it valid regex or not - probably using the java.util.regex.Pattern class to test it)

And some fields are going to require a sequence of validators... For instance, the Camel Binding's "configURI" field is mandatory and must be a valid URI. And the "interval" field on a Rules Logger element is optional (so can be empty), but can use property substitution and if not escaped properly must be a valid number...

Here's an example, creating a new Camel Binding...

How far do we go with this? I think we can definitely handle whatever needs to be done, but I'm curious what you think...

[kcbabo]

Is it possible to flag it as an error but not prevent forward progress or completion of the wizard?  Reason I ask is that it is inevitable that there will be a disconnect here and here between the tooling and runtime (e.g. runtime gets more permissive with a field by adding something extra, or we just make a mistake in the validation logic in the tooling).  When I know I have a valid input and the editor stops me from moving forward I find it incredibly frustrating.  If we just throw up an error without holding back progress, then we can be very aggressive in validation as the user can still proceed if we are too aggressive and/or wrong.  If we must hold back the user with validation errors, then I suggest that we remain conservative with the amount of validation.

In general, I prefer "this doesn't look right" over "I won't accept this".

[bfitzpat]

Yes, we can denote error vs. warning I believe. Do you have an example of somewhere we should apply that more permissive validation approach?

[jorgemoralespou_2]

Hi Brian,

I do agree with Keith, and since today I have criticized the IDE, I have no other option than provide you with my feedback.

I would rather complete the process, and create a "problem" in the "problems view" and also a "quick fix action" to go direct to the point where the problem is and the fixing. Also, it may be a good idea to have an option in the preferences to "disable validation errors", or a select on which validators are enable/disable.

This seems a consistent approach with the rest of JBoss Tools :-D

[bfitzpat]

Jorge,

We appreciate the feedback!

There are multiple levels of validation in Eclipse. What you describe already exists - there's a "SwitchYard Configuration Validator" that should appear in the list on Preferences->Validation that is installed with the SwitchYard tooling. That works similarly to how you describe the rest of JBoss Tools/JBDS.

What I'm describing as far as field-level validation is a bit different and applied specifically on the shared UI we use between the New Binding wizards and the binding properties available in the property view and property dialogs. So though I agree with you to a point - we're already using the approach you describe to a degree. We will probably need to work through some additional problem markers/validation passes to get anything we're missing and add some Quick Fix capabilities, but we hit the high points at least using that methodology in the tooling framework.

--Fitz

[bfitzpat]

kcbabo -- I've made the URI validator spit back a warning vs an error and you get this, which doesn't prevent the user from moving forward.

The only issue I see is that the warning occludes the description at the top. We could probably have the wizard page & property pages check to see if it's a warning vs. an error and just leave the warning decorator as the tooltip and not overwrite the page description.

WDYT?

[rcernich]

I don't think this is an issue since that's standard property/wizard page behavior.  One thing I do think we should look at doing is making the text more descriptive.  In this example, it's pretty obvious, but if there are multiple fields with warnings, it may be difficult to decipher which field the message applies to.  I don't think this is that big a deal though.

[bfitzpat]

We can certainly prefix some of these warnings generated from other places (i.e. the unknown protocol message comes from the URL validation MalformedURLException)... so we have plenty of control over what goes in the validation message. Something like "Config URI - unknown protocol: smtp" would help for sure.

[bfitzpat]

Something along these lines perhaps?