What is the canonical Rails method for collecting and storing physical or email addresses?

Question

I need to collect and store email addresses in a Rails application (2.3). Is there a Rails way for email addresses? For example, I would do f.date_select to create a series of drop-down lists for processing dates, which are then stored in a database, which I defined in the schema and migration as t.datetime "foo" . I would think that canonical Rails is a way to handle dates, and I'm curious if there is an analogue for physical addresses, postal codes, etc.

Answer 1

There is no installed system or assistant for this, because, unlike a date picker, which is more complicated than it seems, collecting address information is quite simple. However, if you need to collect address information in your application and attach it to several things, you can use a combination of polymorphic associations, nested attributes, and a general representation.

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

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

It may seem complicated at first, but it is really very simple. The advantage is that your addresses are the same in all views in your application. And each object with an address has the same setting, even if you change the addresses in the future.

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

Answer 2

Not. Addresses, postal codes, etc. Just considered as strings / integers. There is no specific database type to display these elements, and no specific rail classes are defined for these elements.

I am also not familiar with any ActiveSupport support (the library used by b Rails) for mailing addresses, but I could be wrong here.

Perhaps if you are looking for gems that you can find, this will make it easier to work with these elements.

Answer 3

I began to study this - addresses at the international level are not simple. So far I have found a couple of gems:

• Biggs can format addresses for more than 60 countries. https://github.com/yolk/biggs
• jt-rails-address includes geocoding with Google Maps for autocompletion: https://github.com/jonathantribouharet/jt-rails-address
• The geocoder processes addresses and searches by proximity: https://github.com/alexreisner/geocoder

Even if you are not using any of these gems, it might be worth a look how they store different parts of the address. The general consensus is to have a polymorphic address table, but there are some options for which columns you need.

This article provides some examples of the different ways in which you can treat the form as specific or general, as you need, in different countries, mention some inconsistencies that may arise in different regions (even in this country): http: // www.uxmatters.com/mt/archives/2008/06/international-address-fields-in-web-forms.php

For example, you do not want the zip code to be mandatory, as not in all countries. Depending on how difficult you want to go, you may first ask the country and have different forms depending on the answer to this question. There is a good blog post about avoiding ambiguity, especially regarding the addresses line1 and address line2: https://baymard.com/blog/address-line-2