C'est donc une norme en fondement de chaque adresse et je m'interroge sur pourquoi? P>
Ligne d'adresse 2. C'est dans toutes les formes qui demandent des détails de l'adresse. Cela ne me semble jamais nécessaire. Il nécessite un autre champ dans la base de données et tout le maintien de Goofy qui va avec elle. Chaque fois que vous utilisez une adresse, vous devez le concaténer et 99% de la ligne de temps 2 est vide. L'autre 1% du temps que vous auriez pu simplement mettre en ligne 1. p>
Au lieu de l'appeler la ligne 2, ne pouvait-il pas être appelé quelque chose avec une sémantique plus claire ... comme "Numéro d'appartement"? p>
Il ruine la sémantique de l'ensemble du concept d'adresse. Vous ne savez pas vraiment ce que vous avez dans l'un ou l'autre domaine. Sauf que peut-être que la concaténation des deux domaines entraîne une "vieille adresse". Mais "la ligne 1" et "la ligne 2" eux-mêmes n'ont aucun sens. Est quelque chose "supposé" aller dans chaque respectivement? Je ne l'ai jamais vu. Pourquoi n'avons-nous pas d'adresse ligne 3 pendant que nous y sommes? P>
J'y ai pensé et j'ai compris que, par conséquent, je ne fais pas confiance aux données d'adresse de ma base de données. Tout le champ est flaky en général parce que vous ne pouvez pas vraiment faire de la validation (certaines adresses ont des routes et un numéro de maison, d'autres ont des rues et des avenues). Sauf ces jours-ci, vous pouvez faire quelque chose comme valider le champ contre une API de géolocalisation. Mais simplement à cause de la chose «Line 2», vous ne pouvez pas vraiment être certain de ce que vous faites. Devrais-je combiner la (ligne 1 + ligne 2), puis valider? Que puis-je faire avec l'entrée originale des utilisateurs si je les corrigeez ("Avez-vous voulu dire xxx")? Dois-je juste dire: "Yah, line d'adresse 2 ne fait rien vraiment ... Je viens de prendre votre entrée validée et je suis largué en ligne 1." Pourquoi je donne même l'utilisateur final (et moi-même) la chance d'être confondu. P>
La façon dont je le vois, le champ devrait soit une adresse (rue + maison), ou si nous allons diviser les choses, le faire correctement et demander le numéro de la route et de la maison de manière autonome. P >
4 Réponses :
Ce n'est pas toujours un numéro d'appartement. Ce pourrait être un étage (maison unique, plusieurs résidences) ou d'autres choses. P>
Numéros de la suite, arrêts de courrier, noms de sociétés, etc. Et lorsque vous entrez dans des adresses étrangères, il est courant que certains endroits disposent d'adresses de ligne multiples.
L'adresse première ligne est parfois utilisée par les entreprises pour un nom d'attention, qui rend l'adresse 2 nécessaire pour l'adresse elle-même. Imaginez quelque chose comme: p>
Nom: Microsoft P>
Adresse 1: Att.: Bill Gates P>
Adresse 2: une méthode Microsoft P>
... p>
En réalité, dans de rares cas, un utilisateur peut même souhaiter une ligne d'adresse troisième em>. La meilleure solution à cela consiste à utiliser un
Ho \ nw m \ nan \ n \ n \ n yo \ n \ n nd \ ndr \ n \ ns l \ NAB \ n \ NU p \ NRI \ n?
Même si le champ n'est pas un textarea, un utilisateur intelligent peut toujours envoyer un message HTTP avec de nouvelles lignes dans les champs Address1 et Address2. De toute façon, vous devez gérer des nouvelles lignes inattendues!
Il ne s'agit pas d'une entrée malformée, il s'agit de dire à l'utilisateur que vous pouvez accepter n'importe quel nombre de lignes d'adresses (en présentant une textarea) et que vous ne trouvez que plus tard, après que l'utilisateur ait longtemps disparu et que vous imprimez l'étiquette d'adresse, que vous pouvez ' t gérer leur entrée (valide).
Comme auparavant, avec tout type d'entrée, vous allez devoir regarder de nouvelles lignes. Peut-être que vos étiquettes peuvent gérer des adresses de 21 lignes. Peut-être seulement trois lignes. Appliquez une logique commerciale pour valider l'entrée comme vos besoins dicter, quel que soit le type de champ d'entrée. Ne comptez pas sur un élément UI pour effectuer une validation de données pour vous.
Autoriser une entrée de données en vrac n'est jamais une bonne idée. Si vous devez prendre en charge une adresse multiligne, utilisez 2 zones de texte appelées adresse1 et adresse2. N'utilisez pas de format d'entrée non structuré (Textarea) pour collecter des informations structurées (une adresse). P>
Entraînant le champ d'adresse dans des champs structurés tels que la maison no, la rue, la suite, etc. serait une autre solution.