>From the question I guess that you have added multiple "standard" address and phone fields to the contact record, i.e. you have something like home_address, work_address, home_phone and work_phone *columns* in your table, which I think is a bad idea to begin with. This makes it very ugly to do stuff like 'who has the phone XXX' or who lives in New York etc. The right way to do it is to have a separate addresses and phones tables and to have a separate record there for any phone/address you have for the contact. Then your 'standard' fields will be just suggestions in the interface for the 'description' field of a relevant record. i.e. in the database there will be no difference between 'home address' and 'my super secret hideaway address' other then the 'description' text. As an additional benefit this approach will make it practical to break down the records into subfields, e.g. address, city, zip code, country. etc. (and it would be absolutely insane to do it while stuffing all into a single contact record, or you would end up with literally hundreds of fields)
to make the access 'transparent' to the rest of the app you need to consider 2 things: since there is no difference between the records you can access them all the same. i.e. you have contact.addressess, contact.phone_numbers etc. you can have custom methods on the associations to do stuff like contact.addressess["home address"] if you really need it :) On Jul 17, 2:02 am, lunaclaire <[email protected]> wrote: > I'm working on a contact management app and 3 of the requirements are: > > * the user should be able to add additional custom Contact fields > (e.g. an extra phone number that isnt provided in the std set of > fields) > * the user should be able to name fields with whatever label they want > (e.g. one user might label with "Vacation Phone", another as "Home > Office Phone" > * the custom data will be typed and grouped so that we know that it's > text data vs a phone number (for example) and so that we can get the > list of all custom phone numbers or addresses > > I'm more concerned with the first req right now regarding storage and > the best way to then access and use this data, but am glad to hear > thoughts on the others as well. > > My thought is to have a column in the DB called "custom" that's a text > field and then either go with a YAML style or XML for storing the > field label and data. > > But, what's the best way to encapsulate and do things in the model > code to make these attributes accessible from the rest of the app in a > way thatis transparent to those other parts of the app? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" 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/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
