1 of 1 people found this helpful
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".
Yes, we can denote error vs. warning I believe. Do you have an example of somewhere we should apply that more permissive validation approach?
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
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.
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.
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.
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.