View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Milestone 4 - Read GEDCOM files and provide a multi-generational view

Requirements

Spring2004 M4 - Read GEDCOM files and provide multi-generation views

Read and Write GEDCOM files

The major change for this milestone from what the CS Majors had to do is that we had to retain information that we didn't support in the file format. We saved a lot of time here because we simply needed to modify their reading/writing code to not drop the old data like it had before.

Provide a multi-generational view

This multigenerational view was already in place. Where the CS Majors had failed was in the ability to remove relationships and consistency checks.

Removing relationships

The CS Majors had a rather modular framework for adding relationships. A CustomMenu on the PersonMorph handled the setup of the symbols. When you click on the next person, the GUIController gets those symbols and defines the relationships on the current selected people. Because this was done using perform:, only Person and PersonMorph had to be modified.

Consistency Checks

The CS Majors had designed the program with no as-you-define consistency checks. This would become the biggest hassle of coding with their work. We added consistency checks to the defines on relationships, only to discover that the GEDCOM reading/writing code used the Person and Family class in all sorts of strange, and inconsistent ways. After looking at their code, we decided that Family would no longer be used by the GUI, and it would simply be a class for representing the FAM tag in GEDCOM (it was used more often that way than not). Thus, we were able to move forward and add our consistency checking.

Major Bugs in CS Majors Code

The biggest bug we saw in the CS Majors code was that the there was never an update on the PersonMorphs when things changed. The event system was non-existent really. What was there was also using the old MVC model of self changed:#symbol rather than the cleaner looking self triggerEvent: #event.

The solution was to add these triggers to Person, and make PersonMorph listen to them. This presented the problem then that a Person could be edited in two places. The repetitive code was obvious, so we wrote PersonEditMorph. PersonEditMorph could be used like this from anywhere in the application:
PersonEditMorph with:personToEdit finished:#symbolToCallWhenDoneEditing: on:whichClass

When the user clicked "Done," whichClass symbolToCallWhenDoneEditing: editedPerson was called. This allowed all editing functions to be put somewhere else, so all validation was done in one place and the event notification could be cascaded properly. This will later be used to greatly simplify our searching.

Of all of our additions and improvements, PersonEditMorph is a must see. Designing a class to function in such a generic way that the calling class doesn't need to know anything about is really just wonderful. If your class was already listening to the Person that you send to the PersonEditMorph, then you might not need to be notified that it's finished at all. This is really what events are for, so do take a look.

Files


Link to this Page