« - »

Look-up Tables: Possible refactoring

27 July 2008

One of the things that I like about the approach used in the developerWorks tutorial that I read the other day is the way in which they set up their URIs. It’s actually closer to what I had laid out originally, but that’s not what I ended up using. Right now, there are four distinct URIs in use in this little subsystem:

/table - all tables
/table/<tableId> - one table
/entry/<tableId> - all entries for one table
/entry/<tableId>/</entryId> - one entry from one table

Using the approach laid out in the tutorial, those same four URIs would look like this:

/table - all tables
/table/<tableId> - one table
/table/<tableId>/entry - all entries for one table
/table/<tableId>/entry/</entryId> - one entry from one table

It’s not all that different, I know, but it just seems to be the more consistent, aka the more “appropriate”, way to go about it. I don’t think I will change it right at the moment, but I have to say that I do like it much better.

One other thing that I think I am going to have to change is the amount of metadata stored for individual properties. There are a couple of things that have come up in the development of the remaining pages that has me seriously considering updating the property table in the database.

One of those items has to do with the list of entries for any given table. Right now, the list of entries includes the entry id and the description. However, there is sufficient room to include selected properties on the data grid for this list as well. Depending on the number of properties defined in your look-up table, you may even want to display them all on the entry list, but I don’t think that you would always want to display them all, which leads me into thinking that a “Show this property on the list?” attribute would be another data point that would be useful to keep for every property.

Another, similar useful tidbit of information would be something like “Is this property required?” This would be helpful in data validation for the entry edit page, and would help maintain the validity of the information in the look-up table. Right now, when doing data validation, I don’t think it is helpful to make every property a required entry, but it is certainly possible that some properties might be required, and I think that there should be a way to specify that.

Two boolean flags in the LookupTableProperty object would cover these new requirements, and I probably should go ahead and throw them in before things progress too far, but on the other hand, I hate making design changes right in the middle of something that isn’t quite complete yet. And of course, if I do decide to go back and make changes, then is that a good time to go back and change the URI strategy as well? Forge ahead, or go back … it’s always a tough decision.

Or maybe I’ll just wait and decide tomorrow!


http://blog.restafarian.org/2008/07/lookup-tables-possible-refactoring/

Comments are closed.

Sorry, the comment form is closed at this time.