Bug 284908 - [DataBinding] DialogPageSupport/WizardPageSupport - allow errors to be suppressed until a field is touched
Summary: [DataBinding] DialogPageSupport/WizardPageSupport - allow errors to be suppre...
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.5   Edit
Hardware: PC Windows Vista
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-28 13:48 EDT by Will Horn CLA
Modified: 2019-09-06 16:08 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Will Horn CLA 2009-07-28 13:48:30 EDT
Build ID: 3.5

WizardPageSupport/DialogPageSupport have the intelligence to hide page error messages initially.  But as soon as any field changes, the page errors are shown even for untouched fields.  For example:

___________________                ___________________
Enter your name.                   (X) Last Name is required
___________________                ___________________
                        --->
First Name: *______                First Name:  _Will_
Last Name:  *______                Last Name:  *______

As indicated above, I use FieldDecorationRegistry.DEC_REQUIRED to decorate required fields.  So I would like the asterisk to speak for itself until the user has actually interacted with the field.  

I use a custom error status that is aware of whether it is the initial validation status (untouched field).  But I see no clear way to provide custom handling for it in DialogPageSupport.  The best I have come up with required me to subclass DialogPageSupport and copy/paste handleUIChanged, handleStatusChanged() and handleStatusException().  The first two methods have a @noreference and the third is private so this is clearly not desirable.

I don't know if this "feature" should be added to the platform or not.  But at a minimum, it would be good to have a mechanism to customize the status handling so this type of feature can be implemented using the API.
Comment 1 Ovidio Mallo CLA 2009-09-19 08:57:00 EDT
Will, you might want to check whether the API proposed in bug 248877 would cover your use case as well. I think it's not exactly the same thing but it might work for you as well. There's a patch along with a snippet attached to that bug so you may have a look at it.
Comment 2 Will Horn CLA 2010-02-05 01:19:20 EST
(In reply to comment #1)
> Will, you might want to check whether the API proposed in bug 248877 would
> cover your use case as well. I think it's not exactly the same thing but it
> might work for you as well. There's a patch along with a snippet attached to
> that bug so you may have a look at it.
The code base in which this came up is now obsolete and unfortunately I don't have an easy way to check you new API. Feel free to close this bug if you think it is sufficiently addressed.
Comment 3 John Arthorne CLA 2010-04-30 13:35:06 EDT
Removing obsolete target milestone.
Comment 4 Eclipse Webmaster CLA 2019-09-06 16:08:22 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.