>>>>> On Fri, 25 Sep 2015 09:40:42 +0200, Frank Caputo <frank_at_frankcaputo.de> said:
FC> Hi Ed,
FC> I looked at the branch. Here are my findings:
FC> - Can we hide BeanValidator.getMultiFieldValidationCandidates and
FC> BeanValidator$ComponentValueTuple? They seem like an implementation
FC> detail
You are 100% correct there. I would love to get rid of them, but given
that the current design amounts to a contract between two parties:
Producer:
The <f:validateBean /> validators, which are true
javax.faces.validate.Validator instances and thus must be nested within
UIInput components.
Consumer:
The <f:validateWholeBean /> tag, which is a UIInput subclass that has
its own private validator instance that uses the data from the producer
(please don't suggest we try to use a CDI producer for this).
It seemed necessary to specify them to ensure interoperability of
implementations.
FC> - There are different methods to create the copy of the bean, but
FC> dont we need a deep clone in all cases? Can we do some proxy magic
FC> instead?
>>>>> On Fri, 25 Sep 2015 10:38:15 +0200, arjan tijms <arjan.tijms_at_gmail.com> said:
AT> Not really. Suppose I have a bean with instance fields for a
AT> MyComplexDependency and two Strings, then only bind those two Strings
AT> to input components, and subsequently only apply BV constraints to
AT> these two Strings. In this case a full clone (copy) of the bean is not
AT> needed in order to test the constraints.
Arjan is 100% correct here. In fact, you don't want a deep copy.
AT> Note that the copy strategies are based on
AT>
http://showcase.omnifaces.org/validators/validateBean
FC> - The backing bean in the demo implements Cloneable, to make the
FC> feature work. This feels uncomfortable.
AT> Serializable is another option, and perhaps more accepted. Quite a lot
AT> of backing beans already implement it since a number of (CDI) scopes
AT> require it. If you know that all values to be validated will be set
AT> and/or there's never any previous state to be taken into account, the
AT> "new instance" strategy is normally the best one.
Ok, let's reorder the copy operations to be
1. newInstance()
2. Serializable
3. Cloneable
4. copy ctor.
5. throw FacesException
FC> From my point of view, it seems a little bit unwieldy. Maybe bean
FC> validation is not flexible enough to do multi component validation.
FC> Perhaps we should go a special JSF way:
I'm going to invoke executive authority here and insist the solution be
done with Bean Validation. This is the platform. If people want JSF
specific solution, it can certainly be done, and has been done.
Frank, your point about implementation details leaking out is well
taken. I'll see what I can do about that.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 29 Business days til JavaOne 2015
| 44 Business days til DOAG 2015