Java Reference
In-Depth Information
That's great when we're validating all user-entered fields, but some-
times we want to prevent binding for some properties while still allow-
ing other properties to be bound even though they are not validated.
We have two options to achieve this.
The first option is to use an empty
@Validate
annotation on the property.
This effectively allows the property to be bound without performing any
actual validation.
The second option is to use the
allow=
,
deny=
, and
defaultPolicy=
attri-
butes of
@StrictBinding
so that we can control exactly which properties
are allowed and denied. In the previous example, say we weren't using
any validation at all. We could specify which properties are allowed in
the
allow=
attribute:
package
stripesbook.action;
@StrictBinding(allow={"user.firstName", "user.lastName"})
public class
UserForm2ActionBean
extends
BaseActionBean {
// No validation
private
User user;
/
*
...
*
/
}
If there are many more allowed properties than denied properties, it
becomes more convenient to allow all properties except for those indi-
cated in the
deny=
attribute:
@StrictBinding(allow="user.
*
", deny="user.activated")
Notice the special
*
that matches all properties, but not nested proper-
ties. That's convenient to allow binding at one level but prevent users
from injecting values into more deeply nested objects. If, on the other
hand, we want to allow all levels of nested properties, we use
**
, as in
allow="user.**"
.
So, what happens when a property matches both the
allow=
and
deny=
patterns or neither? That's when the value in the
defaultPolicy=
attribute
is used for the final decision. The value can be
Policy.ALLOW
or
Policy.DENY
(
DENY
is the default).
In the previous example with no validated fields, the following won't
work to block just the
activated
flag:
@StrictBinding(deny="user.activated")
Search WWH ::
Custom Search