Skip to content

Instantly share code, notes, and snippets.

@hale
Last active August 29, 2015 14:01
Show Gist options
  • Save hale/45f4daa5c26cc457a581 to your computer and use it in GitHub Desktop.
Save hale/45f4daa5c26cc457a581 to your computer and use it in GitHub Desktop.

Contact Manager: Notes

Rails 4.0.4

  • There's some compatibility issues between Rails 4.1 and PgSearch which I might use for steps 2-3, so sticking with 4.0.4.

Validations

  • Does not validate against whitespace-only fields or fields beginning with whitespace.

  • The database has strict validation, but this means for UX we must attempt to parse user-input to the strict form, so that there's no requirement for users to adhere to our formatting rules. E.g. automatically parse "123.123.1234" into "123-123-1234"

  • ZIP code validation based on list of US states incl. abbreviations.

    • This would probably be better in YAML in case the same list is needed elsewhere, e.g. JS validations.
    • Would have been better to use the ISO 3166 standard, and perhaps this gem: https://github.com/hexorx/countries
  • Wanted to use Judge for client-side validations, but Javascript regular expressions do not support unicode / posix character classes. Don't want to deal with regular expression compatibility issues so this is a dead end for now.

Associations

  • Since contacts can be grouped by household, I am assuming that we might want to have contacts sharing an address. Therefore the foreign key is on the Contact model, such that multiple contacts can share the same Address record.
  • Since contacts have many phone numbers, the foreign key for numbers is on the PhoneNumber model.
  • Long-term it would probably be better to either not have sharing of address records and duplicate the data (with foreign key on the Address table), or have a join table if many addresses per contact is desired.
  • Deleting a Contact will delete all associated Phone Numbers. Also implemented on the DB level.
  • Foreign key constraints added for associations. This reduces the risk of database inconsistency.

Matching against existing contacts

For the sake of simplicity, going to do this by having an autocomplete form on the first and last name, and have the items in the autcomplete form link to an edit page for that contact. This allows you to both select and update that contact - edit details and add anything that's missing - without making a complicated UI that's both a 'new contact' form and an 'update existing contact' form.

That might actually be the better approach, but it would require further thought on the design and I'm keen to move forwards with functionality.

Wildcard searching

This is a separate search feature, but can use much of the code from step 2.

Wild card searches on partial matches will be done with trigram searches.

Household contacts

Contacts can be grouped together in a household. I thought it would be interesting to interpret this as contacts having the same household have the same address.

When using the search feature to locate contacts, it is possible to group the contacts together by household.

Originally you had the idea to have householding as equal to having the same address, but this isn't necessarily true, isn't stipulated and doesn't make much sense in the context of this task.

Therefore the grouping of contacts will probably require another field on Contacts.

TODO

  • Style the autocomplete box so it's legible
  • clicking on the suggestions takes you to the edit page
  • Create an edit page
  • Edit page should probably not autocomplete..maybe. See how it looks first.

3.

  • Add trigram extension to postgresql in order to allow for partial matches. Wildcard.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment