Community
Participate
Working Groups
Since validation errors coming from missing input ("required validation") sometimes have a special semantics, it would be good to have some way of easily identifying such validation errors in order to automatically process them in a special way. One such example is the ControlDecorationSupport class which might display such validation errors using a FieldDecorationRegistry.DEC_REQUIRED decoration (an asterisk) rather than an actual error icon. One possible way of achieving this would be to introduce an IValidationStatus interface which extends IStatus and which provides some means of identifying the validation status as a "required validation". A "required validation" would then essentially be a normal ERROR IStatus but with some additional information identifying it as a "required validation".
I like it. I'm thinking e.g. ValidationStatus.required("start date is required."); for API.
(In reply to comment #1) > I like it. I'm thinking e.g. ValidationStatus.required("start date is > required."); for API. Sounds good! Regarding the subinterface of IStatus, do you think that a simple marker interface for "required validations" would be enough, i.e. something like IRequiredStatus or do you think that there might be need to support other validation flavors in future. In the latter case, we might want a more generic IValidationStatus interface which has some other means of identifying it as a "required validation" (and something else in future). I personally do not see any need right now for a special validation flavor other than a "required validation".
My gut reaction is that we shouldn't expose an extension interface until we're sure we've covered all our bases. On the other hand, there has to be some way to identify the status as a "required" type constraint error. One possibility (this is just the first thing that came to mind) is to add a method on e.g. IValidationStatus that returns a collection of status tags, and to make a "required field" tag one of those possible tags. But that's just one idea. Really we need to investigate what other types of status identifications might be useful and go from there.
What we have in our project is the following simple subinterface of IStatus: public interface IRefinedStatus extends IStatus { int REQUIRED = 1; int getRefinedStatus(); } along with a static method just like the one you are proposing in a RefinedStatus class: public static IRefinedStatus RefinedStatus#required(String message); The above interface basically just mimics the IStatus interface and simply provides some finer distinction of the actual type of status. Is the above more or less what you had in mind?
No, what I was thinking was more like enhancing ValidationStatus as follows: interface IValidationStatus { public Collection getTags() } class ValidationStatus extends Status implements IValidationStatus { public Collection getTags() } We could provide a "required field" tag by default, but also allow end users to tag statuses with whatever concepts they deem important. e.g. we could stick the ValidationStatusProvider (Binding) in there. I haven't thought this through extensively--I'm just exploring options to see if there's a more general solution so we don't have to come back to this every time we want to support a new UI validation concept.
The IRefinedStatus interface above was actually also intended to be extensible by returning a bitset if need arises. Regarding the possibility that clients attach their own tags to a validation status, I think that in this case I would rather require clients to implement their own interface and do whatever they want since in such cases I see no real benefit in clients being able to actually use an interface provided by the framework rather than implementing their own, mainly because even if clients have their own custom tags, the framework will do nothing with them. Rather, I think we should just provide an extensible way for tagging validation statuses with metadata which actually influences the way some classes of the framework (like e.g. ConstrolDecorationUpdater showing an asterisk for required validations) react and let clients define their own stuff if they really need to attach additional data.
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.
