>>>>> On Mon, 9 Nov 2015 22:51:45 +0100, arjan tijms <arjan.tijms_at_gmail.com> said:
On Mon, Nov 9, 2015 at 10:32 PM, Edward Burns <edward.burns_at_oracle.com>
EB> I wanted to share one additional point of feedback from my JavaOne
EB> co-speaker Lars Bilger at Lufthansa systems. Lars suggested we add an
EB> option to disable the copy and just populate the bean eagerly. This
EB> seems like a fine option to me.
AT> That's a good suggestion indeed. If I understand the suggestion correctly
AT> then this is what I implemented in OmniFaces as well using the
AT> "validateMethod" attribute:
AT> "validateMethod
AT> Set the class level validation method, which can be either 'validateCopy'
AT> or 'validateActual'.
AT> If set to 'validateCopy', then it will perform the validation on a
AT> copy/clone of the actual bean. This has the advantage that the validation
AT> can be performed before the model is updated.
AT> If set to 'validateActual', then it will perform the validation on the
AT> actual bean instance. This has the disadvantage that the validation can
AT> only be performed after the model is updated and thus the action method
AT> will always be invoked regardless of the validation outcome.
AT> Defaults to 'validateCopy'. This attribute is ignored when the 'value'
AT> attribute is unspecified."
AT> See:
http://omnifaces.org/docs/vdldoc/2.1/o/validateBean.html#validateMethod
Yes, you understand it exactly.
However, I propose a simpler API along the lines of what was suggested
by Lars. I propose we add a new attribute to <f:validateWholeBean>:
boolean eagerPopulateValue
If and only if this attribute is specified with a value of true, the
bean referenced by the value attribute is populated with the candidate
values directly and the class level validation is performed directly
on the bean rather than the copy-then-validate process described
above.
Is this ok?
>>>>> On Tue, 10 Nov 2015 09:34:40 -0500, Kito Mann <kito.mann_at_virtua.com> said:
KM> While we're on the subject, is there a way to provide a handler to do the
KM> actual validation instead of handling it via Bean Validation? So basically
KM> the method would just get a reference to all of the validation constraints?
KM> I know there is strong interest in using Bean Validation for all new cases,
KM> but to be quite honest, many of my clients don't use it. We really should
KM> have proper hooks for alternative methods (sometimes validation is handled
KM> completely in the back-end, perhaps driven by a rules engine).
No, we don't have such a thing. Because this is something in the core
JSF spec, I'm going to push back on any solution that doesn't leverage
Bean Validation. Extensions are free to provide their own solutions.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017