What is the canonical Rails way to collect & store physical or mailing addresses?

I need to collect and store mailing addresses in a Rails (2.3) app. Is there a Rails way to do mailing addresses? For example, I would do f.date_select to genera开发者_高级运维te a series of dropdowns to handle dates, which are then stored in the database, which I defined in schema and migrations as t.datetime "foo". I would consider that the canonical Rails way to handle dates, and am curious if there is an analogue for physical addresses, postal codes, etc.

---

There isn't a set system or helper for this, because unlike the date picker, which is more complicated than it seems, collecting address info is pretty straightforward. However, if you need to collect address info in your app and attach it to more than one thing, you can use a combination of polymorphic associations, nested attributes, and a shared view.

I give a basic example and full explanation in my blog post here:

http://kconrails.com/2010/10/19/common-addresses-using-polymorphism-and-nested-attributes-in-rails/

It might seem daunting at first, but it's really very simple. The benefit is that your addresses are uniform across all views in your app. And every object with an address has the exact same setup, even as you change addresses in the future.

I think this is ultimately what you were looking for. I hope it helps!

---

No. Addresses, postal codes, etc... are just considered as strings/integers. There is no database specific type to map to these items and no rails specific classes for these items either.

I am also unfamiliar with any ActiveSupport (a library used b Rails) support for mailing addresses either, but I may be wrong here.

It is possible if you search for Gems that you may find one, that makes operating with these items easier.

---

I have started looking into this - addresses are not straightforward on an international level. So far I have found a couple of gems:

• Biggs can format addresses for over 60 countries. https://github.com/yolk/biggs
• jt-rails-address includes geo-coding with Google Maps to autofill: https://github.com/jonathantribouharet/jt-rails-address
• Geocoder handles addresses and searching by proximity: https://github.com/alexreisner/geocoder

Even if you end up not using any of these gems, it might be worth looking at how they store different parts of the address. The general consensus is to have a polymorphic address table, but there are some variations on what columns you need to have.

This article provides some examples of different ways you can handle the form to be as specific or generic as you need across countries, mentions some of the inconsistencies you might encounter in different regions (even within a given country): http://www.uxmatters.com/mt/archives/2008/06/international-address-fields-in-web-forms.php

For instance, you don't want to make zip/postal code a required field, since not all countries have one. Depending on how complex you want to go, you may want to ask the country first, and have different forms depending on the answer to that question. There is a good blog post on avoiding ambiguity, particularly in respect to address line1 and address line2 fields: https://baymard.com/blog/address-line-2