Implementing Sources, Citations, & Repositories

This is a break off from the integrating events and calendar (and location) task.

I just did a lot of work on getting a foundation on impelmenting sources and citations. Clarification: although both sources and citations use the 'SOUR' fact_code, they really are different in specification and it depends on the fact's context as to which it really is (according to the GEDCOM 5.5.1 specs). Aside: I think the reason I work so much to uphold the GEDCOM spec is because we are already heavily using their structure. If we keep relying on the current db structure mucking with the spec is going to make things even more complicated.

I started working on this because it was one of my top priorities, it seems like a good foundation to build other parts from (I added a lot of functionality to the common.inc), and I want to wait until we make some decisions about location ('PLAC') before moving forward there (I will post another task for that). You can see a working demo @ my live prototype. (I do my development locally and then push mostly-working versions to the website.) Nodes of interest: 5, 17, and 22. As of the moment viewing an individual will show individual level sources at the bottom and event sources will display a superscript link to a citation view to see more information. Once at the citation page you can click on the link to see more source information. The final layer on top of that (according to GEDCOM), which still needs to be done, is a repository view. While I was taking one last look before posting I started to get some odd errors on the sources view that I can't figure out about a bootstrap.inc file I don't have. Other than that it all works as designed. Next steps include making them nodes and, in course, making them editable and allowing adding new ones.

As mentioned above I added a lot of functionality to the common.inc. Partly they are functions that pull some of the previous coding out of the individual.inc and view.inc so they can be used more broadly. There is at least one function (family_getfacts(), which I think I originally wrote) which I would like to depreciate and replace with a new one: family_get_subfacts(). They do the same thing but the new one returns a more usable data structure and the name is more meaningful. I would have removed family_getfacts() entirely but the individual.inc still uses it and I didn't want to do a rewrite of that section yet.

Warning, a lot of my code can probably use a healthy dose of cleaning, restructuring, and optimizing. I don't claim it is great but it at least proves the concept and gets us somewhere. Note that it is pretty much essential to understand the fact hierarchy and relationship structure to work on this module. Without that understanding most of the existing code will make very little sense. One of us (I will if I can get the time) ought to write up some definitive documentation about how this architecture works with some examples for discussion. I already started writing little bits of this in my code comments but the work will be in pulling it together and fleshing it out.

All of these modifications were applied on top of the Drupal 5 patch. That means we probably need to get a Drupal 5 fork for the module before I submit my changes to the world or else we will end up with a large pile of patches interdependent on each other to work. I have no idea how to go about doing that. If anyone wants copies of my modified module files just let me know: seth [dot] e [dot] shaw [at] gmail [dot] com (no spaces).