Qual è il modo canonico di Rails per raccogliere e archiviare indirizzi fisici o postali?

Question

Ho bisogno di raccogliere e memorizzare gli indirizzi postali in un'app Rails (2.3). Esiste un modo Rails per fare indirizzi postali? Ad esempio, vorrei fare f.date_select per generare una serie di elenchi a discesa per gestire le date, che vengono quindi memorizzate nel database, che ho definito nello schema e le migrazioni come t.datetime "foo". Considererei il modo canonico di gestire le date e sono curioso di sapere se esiste un analogo per indirizzi fisici, codici postali, ecc.

Answer 1

Per questo non esiste un sistema o un helper impostato, perché a differenza del selettore di date, che è più complicato di quanto sembra, la raccolta delle informazioni sull'indirizzo è piuttosto semplice. Tuttavia, se devi raccogliere informazioni sull'indirizzo nella tua app e collegarlo a più di una cosa, puoi utilizzare una combinazione di associazioni polimorfiche, attributi nidificati e una vista condivisa.

do un esempio di base e spiegazione completa nel mio blog post qui:

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

Potrebbe sembrare scoraggiante in un primo momento, ma è davvero molto semplice. Il vantaggio è che i tuoi indirizzi sono uniformi su tutte le visualizzazioni nella tua app. E ogni oggetto con un indirizzo ha la stessa impostazione, anche se cambi indirizzi in futuro.

Penso che questo sia in definitiva ciò che stavi cercando. Spero possa essere d'aiuto!

Answer 2

No. Gli indirizzi, i codici postali, ecc ... sono solo considerati stringhe/interi. Non esiste un tipo specifico per il database da mappare a questi articoli e non esistono classi specifiche per questi articoli.

Inoltre, non conosco il supporto di ActiveSupport (una libreria utilizzata b Rails) per gli indirizzi postali, ma potrei sbagliarmi qui.

È possibile che se si cercano le gemme che è possibile trovarne una, ciò rende più semplice l'utilizzo di questi articoli.

Answer 3

Ho iniziato a esaminare questo aspetto: gli indirizzi non sono semplici a livello internazionale. Finora ho trovato un paio di gemme:

• Biggs può formattare gli indirizzi per oltre 60 paesi. https://github.com/yolk/biggs
• JT-guide-indirizzo include geo-codifica con Google Maps per riempire automaticamente: https://github.com/jonathantribouharet/jt-rails-address
• Geocoder gestisce gli indirizzi e la ricerca per prossimità: https://github.com/alexreisner/geocoder

Anche se si finisce per non utilizzare qualsiasi di queste gemme, potrebbe valere la pena osservare come memorizzano diverse parti dell'indirizzo. Il consenso generale è di avere una tabella di indirizzo polimorfo, ma ci sono alcune varianti su quali colonne è necessario avere.

Questo articolo fornisce alcuni esempi di modi diversi è possibile gestire il form per essere il più specifico o generico di cui hai bisogno in tutti i paesi, cita alcuni dei incongruenze che si possono incontrare in diverse regioni (anche all'interno di uno stesso paese): http://www.uxmatters.com/mt/archives/2008/06/international-address-fields-in-web-forms.php

Ad esempio, non si desidera rendere il codice postale/postale un campo obbligatorio, poiché non tutti i paesi ne hanno uno. A seconda di quanto complesso vuoi andare, puoi chiedere prima al paese e avere forme diverse a seconda della risposta a quella domanda.C'è un buon post sul blog per evitare ambiguità, in particolare per quanto riguarda i campi address line1 e address line2: https://baymard.com/blog/address-line-2