one related question: any objection to making the case apply to Integer as well as BigDecimal? You have the same truncation-without- warning problems -- a user who enters "1,234" for an integer writes a "1" into the db.
On Jun 1, 1:38 pm, Montgomery Kosma <[email protected]> wrote: > Been poking through the source looking for the "right" place to access > user-entered data from forms before they are updated to the model. My > goal is to clean up BigDecimal to strip thousands-separators, since > commas cause truncation and my users are frequently cutting-and- > pasting from other apps where numbers are displayed with separators. > > convert_type_for_mass_assignment seems to do the same thing for other > types. I propose modifying it by adding this before the final else > clause: > > elsif field_type <= BigDecimal > delimiter = I18n.translate(:'number.format', :raise => true) > [:delimiter] rescue '' > value.delete(delimiter) > > Thought about protecting against misplaced separators, e.g., by using > gsub(/,(\d{3})/, '\1') instead of delete. However, if I do that, I'd > really prefer reporting the error to the user, and not sure how to do > that in a general way. > > One more thought - if not appropriate to add this BigDecimal handling > generally, would it make sense to add a callback to make it easier to > intercept types not caught by the final 'else' ? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Hobo Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hobousers?hl=en -~----------~----~----~----~------~----~------~--~---
