Community
Participate
Working Groups
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.
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.
(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.
Removing obsolete target milestone.
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.