Automatic type conversion

[GoogleCodeExporter]

AFAICT, there is no support for automatic type conversion.  I would like to
be able to bind integer properties to text boxes and have pectin just do
the right thing.  Obviously, type converters should be pluggable as should
error messages for invalid type conversions.

Original issue reported on code.google.com by donald.b...@gmail.com on 8 Jan 2010 at 2:18

[GoogleCodeExporter]

Sorry, obviously not a defect, but can't see how to edit my issue....

Original comment by donald.b...@gmail.com on 8 Jan 2010 at 2:19

[GoogleCodeExporter]

Hi there,

I'm not sure if you can change the type if your not a project member - I've 
updated
the issue to be a enhancement.

There's no automatic type converstion at this point.  Have you tried using a
FormattedFieldModel created with an IntegerFormat?

e.g. 
formattedFieldOfType(Integer.class).using(new IntegerFormat()).boundTo(..);

There is preliminary integer format  in com.pietschy.gwt.pectin.client.format 
that
you can use although it really needs to be updated to provide better error 
message
generation (using a message format etc).

Having said that automatic conversions shouldn't be too hard.  Although I'd 
probably
have to throw runtime exceptions for unsupported conversions (similar to how
collection converters are handled). 

Do you have any use-cases in mind of how you'd like to configure converters and 
the
associated messages?

Original comment by andrew.pietsch on 14 Jan 2010 at 5:45

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I'm actually using pectin as the basis for a auto-data binding solution right 
now. 
Creating the extra form model class seemed heavy weight for simple forms, so 
I've
implemented a widget that auto-binds fields to the object using the 
BeanModelProvider
as my substitute for proper reflection (along with some new methods I can give 
back,
if desired).  It would be nice to be able to automatically convert between the 
data
type in the pojo and the field type, hence this request.

Original comment by donald.b...@gmail.com on 14 Jan 2010 at 7:05

[GoogleCodeExporter]

Sounds cool.  I'd be interested seeing new the methods you've added too.

I've been thinking about how to do the automatic type conversion but there are 
a few
sticking points.  I'm not sure Pectin can include meaningful format messages 
out of
the box (since validation messages are as application specific as colors and 
themes)
and it's not really good UX practice to tell users things like "The value 'abc' 
is
not a valid integer".  It would make more sense for explicit domain types like
YearOfBirth or CreditCardNumber where a single formatting error messages can be
meaningful across an application.

The other issue is that changing the API to support creating formatted fields 
without
formats will create the case where missing formats won't be discovered until 
runtime
(in the following case the boundTo method would barf).

e.g. field = formattedFieldOfType(Integer.class).boundTo(...) 

This does happen in one other place in Pectin but it something I only want to 
do if I
absolutely have to.

Is this feature something that your library could support without adding it to 
Pectin?

Original comment by andrew.pietsch on 15 Jan 2010 at 11:32

[GoogleCodeExporter]

I've already added several methods to the generator:
* getPropertyNames
* getPropertyType

Basically, at this point, I'm using pectin for its binding and as a workaround 
for
the lack of reflection.  Unfortunately, this latter use doesn't work out the 
best due
to its lack of support for nested objects.

Original comment by donald.b...@gmail.com on 25 Jan 2010 at 5:38

[GoogleCodeExporter]

Have you checked out the gwt-beans-binding project?  It supports nested objects 
using
standard property paths.  Another user has created an initial BeanModelProvider 
based
on it - I haven't brought that into pectin yet as it'll require some 
infrastructure
changes to support models that can change they mutability on the fly - 
something I
haven't got around to yet. 

I'm planning on moving this issue back to "New" for now given the impacts on 
the api
and the default message content issues.  I may think of an approach that solves 
this
at some point but it's not clear to me at the minute.

If you're using the FormModel as a basis for your design you should be able to 
add
support for automatic type conversion relatively easily (i.e. you know the type 
of
the property from the provider and you could have your own map of default 
formats). 
If you extend FormModel you'll be able to call the 
createFormattedFieldModel(...)
directly without using the builder api at all. 

Original comment by andrew.pietsch on 25 Jan 2010 at 10:39

• Changed state: New