This milestone required that a genealogy map be imported and exported as GEDCOM files. The import required a parsing method to recreate all the Persons, information, and relationships, and both the import and export functions required file i/o.
In order to do file IO and parse the files we created, we had to make a few changes to the UML. The classes we added were GEDCOM and ParseGedcom. ParseGedcom was mainly devoted to creating a family tree based on a Gedcom file selected via the GUI. GEDCOM was used to write out a Gedcom file based on the information currently entered in the program.
The diagram of how ParseGedcom and GEDCOM interact with person is shown below.
Because our program included the functionality of Gedcom IO, we had to add a way to do this to the GUI.
To create a Gedcom file from the info currently contained in the family tree, you would select Write GEDCOM. If you wanted to populate a tree with information contained in a Gedcom, select Import GEDCOM. For more information on how to use this functionality, see the scenarios.
Also with this milestone, we included a test plan for the GEDCOM and ParseGedcom classes. The table at the bottom did not turn out very good, but if you look at for a second, it will make sense.
File I/O was found to be very easy in Squeak and we had little trouble getting this to work fine. Additionally, for the parsing of the GEDCOM file, the use of a just a simple parser proved successful. The exportation of a GEDCOM file was very simple in that it only required a loop through the collection of Persons. This is where the use of the code and family object proved very helpful. In a GEDCOM file there are people structures and family structures, and each structure needs to be labeled with a unique title. The code was used as the title for each Person, and an extension of the use of the code into family objects proved to be very helpful in titling the family structures in the GEDCOM file.
This is one milestone that I spent a very large amount of time on a very small, stupid issue. In Squeak, there are a few different types of file streams, and Squeak uses a number of different standards in the implementation of new lines. Squeak accommodates for Windows, UNIX, and Mac standards when it comes to new lines: line feeds, carriage returns, etc., are all used. For some reason, the FileStream object I was using to export the GEDCOM file did not use the Windows standard in the resulting file. Thus, when attempting to test my GEDCOM with GED2HTML and GEDpage, a file that was written by Squeak would not work, while a file whose text was copied from Squeak and pasted into notepad would. So, I had two files, with the exact same information, and one would not work in with the GEDCOM programs. Much time was spent testing the files for differences to see what could be the problem, but every test proved, both files were exactly the same. This proved to be the source of much frustration. However, by the grace of God, a search on the issue informed me of the way Squeak handles new lines as well as a solution. In the end, instead of a FileStream object being used, a CrLfFileStream was used, which I believe uses the standards of whatever system Squeak is running on.