Hi
2015-03-28 16:08 GMT-05:00 Michael Müller <michael.mueller_at_mueller-bruehl.de>:
> Hi,
>
> When talking about multicomponent validation, I personally misunderstood the
> intention of this.
>
> During a short EG face to face meeting, we talked about some examples, to
> clarify its intention:
>
> A couple of components might relate to each other. Even though each of these
> components got a valid value, the combination of values might be false.
>
> Examples:
> - A bank account number and a bank location number must fit together,
> validated by a checksum rule.
>
> - two fields, e.g. person's age and birthdate might suspend each other
>
> - A component might be repeated, e.g. password or email. Not only each of
> them must be valid, both must contain the same value
>
> To achieve multi component validation, it is not possible to convert and
> validate component by component. In fact, the conversation and validation
> phase has to be splitted internally: All components have to be converted
> and the the validation is started then. We agreed to support the bean
> validation groups.
>
+1. The problem is UIInput.validate() do many things:
- get submitted value and pass to getConvertedValue(...)
- call to validateValue(...)
- if the field is not valid, return, otherwise pass clear the
submitted value and and call setValue() passing the converted value.
- If the value stored was changed, trigger ValueChangeEvent
We have 3 different things going on in the same method that should be
splitted somehow:
- Conversion
- Validation
- Update Component Information
For multi component validation there are some important cases we need
to think about:
1. If the validation fails, more than one component can be marked as invalid.
2. If conversion fails on a component and a validation affects 2
components, by transitive rule the validation fails on both
components.
The current model applies conversion/validation in the same order the
components are placed in the tree.
Let's try to change the algorithm a bit:
- Add a transient property to keep track of the components where
conversion has been applied and another transient property for the
converted value (EditableValueHolder requires to be updated). If
conversion has been already applied, don't do it twice.
- Don't do "update component information" step on validate(), instead
do something to defer this step (put the change into a queue).
- Traverse the component tree, calling validate() method. If a "multi
component validator" is found, perform conversion step on each
component and all the parent components of the target components (this
is important for components that do some conversion based on the
parent component). Then, invoke the validator and continue til the
end.
- At last, use a visitTree(...) call to do the "update component
information" step on the components added to the queue.
That algorithm will ensure linear complexity. Old components with
validate() method overridden will continue working, but it will not
work for multi component validation without an update, which looks
fine. The new "update component information" step will be useful to
detect what has happened with the validation and take some action if
required.
> I like to add some thoughts:
>
> - It would be nice to hook in the middle of this conversation and validation
> phase, e.g. by a PostConversationEvent
>
> - Beside bean validation, it should be possible to define a validator the
> "JSF way". And it would be nice to support actions depending on the
> validation result, e.g delete or change the content of one or more
> components.
>
> Is my understanding right?
I would like to see a use case that justify these cases. The reason is
I do not want to add unnecessary overhead in that part. We already
have PreValidateEvent / PostValidateEvent, so it should be an use case
that can't be solved with these events.
regards,
Leonardo Uribe
>
>
> --
>
> Herzliche Grüße - Best Regards,
>
> Michael Müller
>
> Read my book "Web Development with Java and JSF": https://leanpub.com/jsf
>