On Tue, 9 Apr 2002, Tim Moore wrote:
> > >
> > > It's still nice that you can use integer properties, though, for
> > > things like select fields and radio buttons...anything that doesn't
> > > allow free-form text input.
> > >
> >
> > How do *you* know that your Struts client is actually a
> > browser (and therefore using the SELECT box to control the
> > input value that is sent)? It could be a program that is
> > submitting HTTP requests to trigger transactions in your webapp. :-)
>
> Then I'm not concerned about it throwing an exception if I get a garbage
> value, or maintaining the garbage value for the response. I still do
> bounds checking of course if that's necessary...it's just nice to have
> the String to int conversion happen implicitly. Same with booleans and
> checkboxes.
>
> Now I guess if I decide to change my form to use a text input instead of
> a drop-down, then I have to go back and change the form bean and action.
> But most of the time, that's not even a remote possibility--like if
> you're choosing an item from a list and it's sending the primary key
> back when you submit.
>
> In general, though, I don't usually bother making "pretty" error
> messages for the types of errors that could have only originated from a
> buggy or malicious client request; I just throw an exception.
> Presumably the response isn't going to be displayed directly to the user
> anyway if they're using a GUI client or something like that. Is there
> any other reason to use only String properties in that case?
Using int properties for a case like this is a very reasonable pragmatic
decision. My primary concern is all the people who try to use a form bean
as a value object -- that approach is just going to get you in to trouble.
>
> --
> Tim Moore / Blackboard Inc. / Software Engineer
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
