Hi Pierre,
>> It might make sense to skip calling the setIntProperty() field at all if
> the
>> input is a zero-length string. JSP follows this rule when you specify
>> something like <jsp:setProperty name="beanname" property="*"/>, so this
>> would be more consistent with JSP as well.
>>
>> What do you think?
> It might create side effects, like with checkboxes where a non checked
> button is not sent to the server.
Checkboxes have to be consired, that's sure. But the exceptional case is the
stupid way, how checkbox-handling is defined for HTML-forms, not the fact,
that the user (and the web-developer) should have the ability to use optional
fields (IMHO).
> Imagine that the user has entered a value in a field, but that field must be
> empty for the form to be validated. When struts redisplays the form with the
> errors, the user empties the field. With your proposal, struts will never
> transmit the empty field to the bean and the validation will always fail...
No, this is not correct. The current codebase should do a formBean.reset()
before populating the bean with the (re-)submitted values. At least, thats
my understanding of ActionServlet.process() and ActionServlet.processPopulate().
> In that particular case, the "" <==> 0 translation creates the whole
> problem. The ActionForm bean should really use String in order to
> distinguish between empty and 0 value. Then, after validation (the
> validation could have to convert the field value in order to check its
> content), the conversion should occur when the definitive values are
> transfered to the business object.
This would be the way to go for simple kinds of validation and low or mid-
performance-range apps. In my case, I would have to pay a performance or
a design-penalty if I do it this way (I think).
Imagine a multipage form, where you want to validate as early as possible
(ie. on the page where the properties have been entered), but also have some
complex inter-relationships between some properties, which are also important
for their validation.
If I understand your suggestion, this would mean
a) that I have to do the String-to-RealType conversion anytime I have to
check the validity of "dependent" properties or
b) that I have to cache the converted value (to workaround the drawbacks
of a) in the bean.
I don't like a) because it's sub-optimal in performance terms. b) on the
other side is questionable (for me), because most of my properties are numeric
properties and that would lead to a bean, where I have nearly every
(String-)property shadowed with a numeric property (the cached conversion).
Given the assumption, that there is a way to change the current
implementation without breaking the checkbox-stuff, I'm still
not convinced.
--
Matthias (mailto:[EMAIL PROTECTED])
