You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by John Yu <jo...@scioworks.com> on 2002/08/08 04:14:55 UTC
Type conversion and exception handling [Was Re: DynaForm and
Converters]
(I'm thinking out loud here. :-)
I see this dilemma:
* We want automation for converting the data types in the formbeans.
Since Struts performs automatic population of the beans already, it seems
'natural' to have Struts does the conversion at the same time.
* However, if Struts does the conversion when populating the beans, we
will lose the control of handling the conversion exceptions if anything
goes wrong.
I'm wondering what if the conversion routine provides some sort of
declarative exception handling mechanism?
<form-bean name="myBean" type="myPackage.MyBean"
conversionExceptionHandler="myPackage.ConversionExceptionHandler"/>
Then the ConversionExceptionHandler.handleEx(String beanName, String
propertyName, Exception reason) is called when exception occurs.
Or even better, make the converter pluggable and each pluggable converter
must also implement the above handleEx() method:
<form-bean name="myBean" type="myPackage.MyBean"
conversionExceptionHandler="myPackage.ConversionExceptionHandler">
<form-property name="property1" converter="myPackage.Converter1"/>
<form-property name="property2" converter="myPackage.Converter2"/>
...
</form-bean>
Does it make sense?
--
John
At 12:27 am 08-08-2002, Craig wrote:
>On Wed, 7 Aug 2002, Thomas Recloux wrote:
>
> > Date: Wed, 7 Aug 2002 18:15:47 +0200
> > From: Thomas Recloux <tr...@norsys.fr>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: Struts Developers List <st...@jakarta.apache.org>
> > Subject: Re: DynaForm and Converters
> >
> >
> > Why do not you think that the basic conversions should be done in Forms ?
> >
> > Their work is to get values from the request so ..why should'nt he "cast"
> > the values to the good types ?
> >
>
>Consider an integer property that (because of the limits of HTML) you
>render as a text input field. Now assume your user types "1a3" instead of
>"123" into the field. What is supposed to happen?
>
>What the user expects, if they've ever used a GUI program of any sort, is
>the following two things:
>
>* An error message of some sort telling what is wrong
>
>* The existing data that was typed will be reproduced
> (even if it is wrong) so that only the bad part can
> be fixed.
>
>If you use a String property in your form bean for this field, both of
>these expectations get met. If you use an int property in your form bean
>for this field, you get a conversion error and an ugly exception.
>
>Moral of the story -- form bean fields that correspond to text entry boxes
>should always be strings, and you should do your conversion later (after
>you've validated that it's possible). For checkboxes, you can use boolean
>properties, because there are only two possible answers.
>
> > --
> > Thomas Recloux
>
>Craig
--
John Yu Scioworks Technologies
e: john@scioworks.com w: +(65) 873 5989
w: http://www.scioworks.com m: +(65) 9782 9610
Scioworks Camino - "Don't develop Struts Apps without it!"
Re: Type conversion and exception handling [Was Re: DynaForm
and Converters]
Posted by John Yu <jo...@scioworks.com>.
I see. Really looking forward to seeing the JSF spec.
At 11:06 am 08-08-2002, you wrote:
>On Thu, 8 Aug 2002, John Yu wrote:
>
> > Date: Thu, 08 Aug 2002 10:14:55 +0800
> > From: John Yu <jo...@scioworks.com>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: Struts Developers List <st...@jakarta.apache.org>
> > Subject: Type conversion and exception handling [Was Re: DynaForm and
> > Converters]
> >
> > (I'm thinking out loud here. :-)
> >
> > I see this dilemma:
> > * We want automation for converting the data types in the formbeans.
> > Since Struts performs automatic population of the beans already, it seems
> > 'natural' to have Struts does the conversion at the same time.
> >
>
>The first part of that is not a leap I'm ready to make yet -- that's not
>why form beans exist in the first place. Their *sole* purpose, as far as
>the architecture of the framework is concerned, is to make it possible to
>reproduce the state of an input page in the face of bad input.
>
>The real issue is that form bean properties are not fine grained enough,
>*or* complex enough, to do all the stuff we'd like. We should really want
>to have components that know how to render themselves, convert themselves,
>validate themselves, render their children (so that you can compose
>complicated things out of simple things), and update the underlying
>model-tier objects. Application frameworks should not have to worry about
>such things.
>
> > * However, if Struts does the conversion when populating the beans, we
> > will lose the control of handling the conversion exceptions if anything
> > goes wrong.
> > I'm wondering what if the conversion routine provides some sort of
> > declarative exception handling mechanism?
> >
> > <form-bean name="myBean" type="myPackage.MyBean"
> > conversionExceptionHandler="myPackage.ConversionExceptionHandler"/>
> >
> > Then the ConversionExceptionHandler.handleEx(String beanName, String
> > propertyName, Exception reason) is called when exception occurs.
> >
> > Or even better, make the converter pluggable and each pluggable converter
> > must also implement the above handleEx() method:
> >
> > <form-bean name="myBean" type="myPackage.MyBean"
> > conversionExceptionHandler="myPackage.ConversionExceptionHandler">
> >
> > <form-property name="property1" converter="myPackage.Converter1"/>
> > <form-property name="property2" converter="myPackage.Converter2"/>
> > ...
> > </form-bean>
> >
> > Does it make sense?
>
>If JavaServer Faces weren't coming down the pike, it might well make
>sense. But the future is going to be much better than what this feature
>would enable, IMHO ... more news when JSR-127 eventually goes to public
>draft.
>
> > John
>
>Craig
--
John Yu Scioworks Technologies
e: john@scioworks.com w: +(65) 873 5989
w: http://www.scioworks.com m: +(65) 9782 9610
Scioworks Camino - "Don't develop Struts Apps without it!
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Type conversion and exception handling [Was Re: DynaForm and
Converters]
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 8 Aug 2002, John Yu wrote:
> Date: Thu, 08 Aug 2002 10:14:55 +0800
> From: John Yu <jo...@scioworks.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Type conversion and exception handling [Was Re: DynaForm and
> Converters]
>
> (I'm thinking out loud here. :-)
>
> I see this dilemma:
> * We want automation for converting the data types in the formbeans.
> Since Struts performs automatic population of the beans already, it seems
> 'natural' to have Struts does the conversion at the same time.
>
The first part of that is not a leap I'm ready to make yet -- that's not
why form beans exist in the first place. Their *sole* purpose, as far as
the architecture of the framework is concerned, is to make it possible to
reproduce the state of an input page in the face of bad input.
The real issue is that form bean properties are not fine grained enough,
*or* complex enough, to do all the stuff we'd like. We should really want
to have components that know how to render themselves, convert themselves,
validate themselves, render their children (so that you can compose
complicated things out of simple things), and update the underlying
model-tier objects. Application frameworks should not have to worry about
such things.
> * However, if Struts does the conversion when populating the beans, we
> will lose the control of handling the conversion exceptions if anything
> goes wrong.
> I'm wondering what if the conversion routine provides some sort of
> declarative exception handling mechanism?
>
> <form-bean name="myBean" type="myPackage.MyBean"
> conversionExceptionHandler="myPackage.ConversionExceptionHandler"/>
>
> Then the ConversionExceptionHandler.handleEx(String beanName, String
> propertyName, Exception reason) is called when exception occurs.
>
> Or even better, make the converter pluggable and each pluggable converter
> must also implement the above handleEx() method:
>
> <form-bean name="myBean" type="myPackage.MyBean"
> conversionExceptionHandler="myPackage.ConversionExceptionHandler">
>
> <form-property name="property1" converter="myPackage.Converter1"/>
> <form-property name="property2" converter="myPackage.Converter2"/>
> ...
> </form-bean>
>
> Does it make sense?
If JavaServer Faces weren't coming down the pike, it might well make
sense. But the future is going to be much better than what this feature
would enable, IMHO ... more news when JSR-127 eventually goes to public
draft.
> --
> John
Craig
>
>
> At 12:27 am 08-08-2002, Craig wrote:
>
> >On Wed, 7 Aug 2002, Thomas Recloux wrote:
> >
> > > Date: Wed, 7 Aug 2002 18:15:47 +0200
> > > From: Thomas Recloux <tr...@norsys.fr>
> > > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > > To: Struts Developers List <st...@jakarta.apache.org>
> > > Subject: Re: DynaForm and Converters
> > >
> > >
> > > Why do not you think that the basic conversions should be done in Forms ?
> > >
> > > Their work is to get values from the request so ..why should'nt he "cast"
> > > the values to the good types ?
> > >
> >
> >Consider an integer property that (because of the limits of HTML) you
> >render as a text input field. Now assume your user types "1a3" instead of
> >"123" into the field. What is supposed to happen?
> >
> >What the user expects, if they've ever used a GUI program of any sort, is
> >the following two things:
> >
> >* An error message of some sort telling what is wrong
> >
> >* The existing data that was typed will be reproduced
> > (even if it is wrong) so that only the bad part can
> > be fixed.
> >
> >If you use a String property in your form bean for this field, both of
> >these expectations get met. If you use an int property in your form bean
> >for this field, you get a conversion error and an ugly exception.
> >
> >Moral of the story -- form bean fields that correspond to text entry boxes
> >should always be strings, and you should do your conversion later (after
> >you've validated that it's possible). For checkboxes, you can use boolean
> >properties, because there are only two possible answers.
> >
> > > --
> > > Thomas Recloux
> >
> >Craig
>
> --
> John Yu Scioworks Technologies
> e: john@scioworks.com w: +(65) 873 5989
> w: http://www.scioworks.com m: +(65) 9782 9610
>
> Scioworks Camino - "Don't develop Struts Apps without it!"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>