Re: [Springframework-developer] PropertyEditing

[Ken K. <kk...@kk...>]

Juergen,

Way cool!! I guess it is pretty flexible, as I should have suspected ;-) 
. I'll be sure to discuss this in the petclinic tutorial.

Ken

jürgen höller [werk3AT] wrote:

>Thomas,
> 
>The reason why there is no automatic support for Integer or Date is that it's unclear how to parse them by default. As you noted, there is more than one way to handle empty values when binding to Integer, and parsing floating point decimals is locale-specific (e.g. "1234.5" in English vs "1.234,5" in German notation), as is parsing Dates. That's why I introduced CustomDateEditor, CustomNumberEditor, and CustomBooleanEditor: They allow you to specify the exact parsing behavior, depending on the current _request_, to be able to respect current locale etc.
> 
>Note that these editors do not only parse strings into the respective property type but also vice versa, being applied on Errors.getFieldValue. So locale-specific form field values can be set to respective bean properties but also rendered in a suitable way on redisplay of the form (e.g. via the bind tag). Without proper framework support, such stuff can be quite tedious to write. Try to achieve this with a Struts ActionForm, for example: Every such field had to be a String there to accept invalid values, and you would have to do all the locale-specific parsing and rendering yourself.
> 
>BTW, we use both CustomDateEditor and CustomNumberEditor in practice at werk3AT. For us, this pattern is convenient and works nicely.
> 
>Regarding distinct "typeMismatch" error messages: Ken, as you've noted, you can specify "typeMismatch.myField" messages for type mismatches on the respective field. Don't forget that you can even specify "typeMismatch.myBean.myField" messages for type mismatches on the respective field of the respective bean ("myBean" being the name of the bean in the model)! What more fine-granular way of associating messages would you need?
> 
>Thomas, if you'd like to add additional options to CustomNumberEditor, e.g. BigDecimal and BigInteger support as you've proposed, please go ahead! We can definitely benefit from more type parsing and rendering options.
> 
>Regards,
>Juergen
> 
> 
>
>	-----Ursprüngliche Nachricht----- 
>	Von: Ken Krebs [mailto:kk...@kk...] 
>	Gesendet: Mi 16.07.2003 22:52 
>	An: tri...@tr... 
>	Cc: spr...@li... 
>	Betreff: [Springframework-developer] PropertyEditing
>	
>	
>	Thomas,
>	
>	<Thomas>
>	Also, is there a way to distinguish betweeen a blank and an
>	invalid number - I get typeMismatch for both, but sometimes a blank could be OK.
>	</Thomas>
>	
>	If you override initBinder() in your Form to install a CustomNumberEditor, you can specify allowEmpty=true in the constructor to allow an empty String to pass through. You can then handle the empty String in your Validator if you wish.
>	
>	It seems to me that PropertyEditors could be fertile ground for useful extension.
>	
>	I do think we need something more flexible in the way BeanWrapperImpl, PropertyEditors, and Validators coordinate error handling. The typeMismatch error strings are tied to a particular fieldName but the same fieldName could possibly be used on different Forms to fulfill a somewhat different function. It's not clear in my mind yet what the right mechanism for doing this is.
>	
>	Regards,
>	Ken
>	 
>  
>