Hi Martin,
I've thought more on the subject and think that we (I) have mixed up two
(mostly) unrelated issues.
a) "Reproducing" the original input when an validation error occurs
I'm convinced now, that to reproduce the original input it is necessary
to save the input made as _String_ properties. My (wrong) assumption has
been, that for all kinds of input you have a unique mapping from
String to targetType and backwards. The backward mapping does not exist
in all cases - for example it would be difficult to reconstruct the
exact input string from a floating point number.
> My understanding is that this is how it's supposed to work. The idea behind
> form beans is that they represent exactly what the user entered, so that the
> same information can be used to populate the form when errors occur. A
b) Should Struts show a similar behaviour as specified for
<jsp:setProperty>
This was my original question and I still think that it would be much
easier to learn Struts, if it would behave the same way as defined
for <jsp:setProperty> in the JSP spec.
The main difference comes from the fact that Struts attempts to convert
empty/missing input to some "meaningful default" value that is then set
as property in the Bean. The JSP spec. however defines that empty request
parameters _must_ be ignored.(*)
In Struts, the bean is unable to distinguish, if the user has left the
field blank or if he itself has entered the "meaningful default" value.
This could lead to various additional problems. One example are optional
form fields.
Here is another example that could not be done with Struts (I think).
Imagine you would change the protocol select control in subscription.jsp
(found in struts-example) to return int's (say 0 for IMAP and 1 for
POP3). The select control should also have an additional entry reading
"Select protocol" that maps to a value of "". In Struts this will not
work as expected. Instead the following behaviour could be observered:
- The user enters some subscription data, but forgets to select the
mail server protocol. The user then submits the form.
- If all other values are validatable, the behind-the-scenes-conversion
will not be noticed from the form Bean. It will think the user has
selected IMAP (Because missing integers are converted to Integer(0)).
--> OUCH!
- If he/she has made some error elsewhere and the form is shown again,
suddenly the not-specified mail server protocol is set to IMAP (for
the same reasons as above)
--> OUCH!
(Of course, this could be solved by associating the default entry
"Select protocol" with -1 or something like that. I just tried to
point out a possible problem.)
Matthias (mailto:[EMAIL PROTECTED])
(*) From pg. 66 JSP1.1:
If the param is not set in the Request object, or if it has the value of ““,
the jsp:setProperty element has no effect (a noop).
