Giovanni Azua wrote:
Personally, I never expose primitives as properties of an action
because null values are always legal over this interface. In the
special case of Boolean which can easily accidentally cause an NPE, I
always make the getter return false if the value is null..
This validation design jeopardizes the flexibility of using any POJO
as a target Action, using classes for which you don't have access to
the source code. Also promotes bad design practices i.e. potentiating
NPEs.
I could try and open a "nice to have enhancement minor" JIRA ticket
for this? Maybe changing the Validation interceptor to do the
validation before is not a big deal. Only problem though is that doing
it before, it may try to validate request parameters that are not
actually used in the Action but maybe there is a way around this.
The validation architecture depends on calling the getters of an action
so no matter where it is in your interceptor stack, it must be called
after the action is instantiated and after the parameters interceptor.
What you describe would require greater coupling between these two
interceptors.
Thinking a little deeper about this, the specific problem for you is
that the conversion interceptor fails silently when attempting to set
your primitive properties to null values. I haven't really played with
the ConversionErrorInterceptor, but it should be possible to force it to
generate a conversion error (and consequently a field error) for your
primitive properties if they are being set to a null value. In the
worst case, you could use a custom converter to trap that case. Make sense?
Hopefully someone with WebWork2/Xwork experience that knows the history
behind this will respond.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
