The future of Family module - Completely Redesigned.

Microbe,
This doesn't necessarily need to be after the port, but it should be after the relationship linking has been finished. One of the big problems here is that it's going to require us to nearly completely rethink and redesign how we are doing things in this module. This is not something we should rush head forward into.

I do think however that this is a good point to start the conversation. I personally would like to propose a complete evaluation of the existing code, what it currently does, and if there is anything that exists already that does it better. I still would like to hold off on implementing this until 6.x, as it vastly improves the way a lot of things occur, such as dynamic menus.

I am changing the title of this thread to make it clear what we're speaking about. Again, here is what I'm looking for in this discussion:

1. What are all of the things that the module currently does. This should be as granular as possible. I will provide more input on this when I have time. We can also include things that we feel a module like this should do.
2. Are there existing modules that do parts of what we need to do?
3. I think GEDCOM compliance should be revisited. Are we missing out on a lot of the power of Drupal but staying so close to GEDCOM standards in functionality. Shouldn't the only times we should be really concerned about this be on import and export? (which doesn't currently exist) Are we actually GEDCOM compliant now? (The short answer is no.)

Please everyone who has an interest in this module, coder or not, chime in and add your opinion. I need to look through the code a bit before I add my thoughts.
Thanks,
Jonathan

the things i think that would be good in future development are:

1. Being able to create family realtions online (i know this is already being developed by pyutaros)
2. Intergration with cck so that you can 'link' people with other nodes/images/other - this should not show when you view the node(optional for the administrator) the list of all nodes linked to a certain family member should then be able to be displayed as a link from the family individuals pages. this would enable alot of node types such as images and other information page types to run from different modules but still be linked with the family individuals. There is already a cck for refenceing a node but what we create should be able to reference multiple people.

possibly also a button that appears above or below text boxes from whiuch you can insert a hyperlinked name to reference some in some text - this might need to be controled by another module - e.g. TinyMCE.

3. GEDCOM merge and export - for this i think the coding has to be changed currently i believe we are unable to do this if we use the current database structure with facts and relations. i see maybe more of a table with all the inididuals and then another table with all the facts linked straight to a single entry in the inidividuals table. a third table for groups/relations should link them similarly to the current situation. The GEDCOM import and export should be coded so that they convert between its stucture and ours it already has to seperate the lines and split them up when inserting into the database so it cant be that different from the current code. we dont want to end up being limited to what we can do by using the GEDCOM structure in our databases.
4. link to timeline module so you can view events in a single persons life and when people lived in a timeline type way. (this i think is not a very import feature currently)
5. the implementation of the citations and sources pages - they are already hidden in the code but im not sure how developed they are what they currently do and how to link them to the family members. (probably just another stupid idea of mine but should this be a seperate module that we allow users to download but just has a lot of intergration into family e.g. a required module? citaions and sources would be useful for more than just geneology stuff im imagining)
6. a simlar thing for locations as with citaions. this is already in the module but just disabled as it is not ready.

linking things to family members (nodes, citations, references etc.) would be alot easier if all the information was linked to the same id (the key in the proposed individuals table) rather than having for example a birth linked to a person then a date linked to the birth a single row should contain the date and the type (birth) and that should be linked to the family_inividual.

i have only been using this module for a sort time and probably dont use it quite as indepth as a geneoagist would so dont know quite what the full protential of this should be or quite what people need so im not sure if my new table idea is practical but it makes more sense to me.

i will look further into what the current citaions, sources and location code does to see if we can use some of it or whether we need to start anew.

hope some of this makes sense im no good at communicating ideas usually
Microbe

Great input Microbe. I'm looking for more of an analysis of where we are, than where we want to go. We already have a wishlist out the wazoo, but no real clear direction or standard on how to implement it. I have to admit I have had a lot of trouble implementing a simple feature such as adding a group content type and the structure for relating it to an individual content type for a few reasons.

1. I'm not a very good programmer to begin with.
2. We concatenate and reconcatenate and the concatenate some more, instead of letting Drupal do most of the heavy lifting.
3. Our existing database structure of facts and relations causes an unnecessary, bulky, and slightly confusing extra layer of overhead.

Seth has some good documentation at http://famhist.shawspace.com/?q=node/46, which should be considered before I go any further. I am going to review this before I respond any further.
Thanks,
Jonathan

i agree with you there. the most important thing currently is to reorganise the database strucuture. i know from experience that once we choose a layout is it easy to update the code (i can do this once we decide on a strucutre if you feel it would be to hard). i looked at the linked page and still dont think the current setup is at all good, there is way too may querys being run to get all the right information. the GEDCOM standard is just one way of looking at the data and as long as we keep the same variable then we can still convert between the two.

i am thinking currently something like this for column headings:

nid (primary key)
Forenames
Surname
DOB
Place of Birth
DOD
Place of Death
Father nid
Mother nid
Biography text (body - this is probably better left in the node table)
Sources (comma seperated array of nid(key) of sources used)

then a seperate table for marriages e.g.

Family id (unique key)
Husb nid
Wife nid
Date
Place

then a third table for cck relationships between nodes this should be used for linking in images, forums, locations and possibly sources instead of in the first table:

nid of page
nid of family_individual
page type

we do not need the children in this second database as we can get them by searching for the parents nid in the other table.
not sure what other data we want to include but as we have a nid row for each person with the most often used variables we can just link it in using that key like the GEDCOM stucture works.

im not sure how you have done the relationships but using the above tables i think it would be easiest to have on the inividuals page choice of spouse and parents via drop down box or nid number (dropdown boxes could get way to big) children will automatically drop out of adding the parents. just picturing the code in my head makes me think it should be really easy doing it this way.

merge and export are easy to achieve as its just a long list linking variables which we already have linked. merge though is still quite hard as for example we might have two people with the same name and no other data but they must have parents or children to be linked into the tree so we can compare them.

if there are any major bits of information that im missing out on please add them in; obviously if there are variables that need to be added on specifically for certain users of this module they can use stadard cck. otherwise i personally think this would create a great structure.

Microbe

Don't be offended if my next reply says things you've already said above. I've been hashing out the old and new for hours today. No matter what the timestamp says, it was started hours before.

Okay. Let's start with the basics. I'm going to list out the general elements of the module and get a little more granular, including suggestions as to how the structure can be improved. We currently have 12 files and 2 database tables associated with the Family module. Remember, I'm also doing this for my own benefit, so I can get my slow brain around everything. Here is the list (This is also an attempt at adding to documentation.):

• Tables
  • family_facts
  • family_relations
• Files
  • common.inc
  • EstimateDates.inc
  • family.info
  • family.install
  • family.module
  • group.inc
  • import.inc
  • individual.inc
  • README.txt
  • source.inc
  • tree.inc
  • view.inc

Tables

The two tables, facts and relations, work in tandem and so should be addressed together. Seth does a great job explaining them in his documentation, so I will try and avoid being too redundant. The family_facts table is basically a line by line import of a GED file. Most of the fields are always empty, except for some special cases. Also, most fields are only populated by the import, node creation does very little.

The family_facts database has 6 fields: fid, nid, fact_code, xref, fact_value, gedcom_source. I will explain what each of these mean, how we deal with them in our data structure, and what they imply about the overall structure of GEDCOM standard.

• FID is basically an incremental index number used for referencing relationships.
• NID is NULL currently unless the FID is a line referencing an INDI or FAM XREF. I will explain XREF below. Suffice it to say that currently we don't handle nodes like many other modules do. Rather than creating a table that contains all of the fields that belong to a node, we create an array built off of fact relationships at runtime of viewing a node. This is one thing that I am going to recommend that changes. I think we should create a content type and table per content type for every root fact, or fact that has an XREF. this will eliminate a lot of the overhead and specific code necessary for each content type. There is a reason it has so far been this way. It's easy to take our current facts structure and export it (if we had an export) back to a GED file. I think the new structure I'm proposing will be just as easy once it's understood.
• FACT_CODE is an identifier for the GEDCOM standard as to what kind of data is being dealt with. I'll take some time here to explain the GEDCOM standard a little.
  • A GED file has a line based structure with each line having a depth number assigned to it. An example of how this works is that an INDI line (a root entity) has a 0, a fact for this individual such as the concatenated name (NAME) is given 1, and the subfacts of the concatenated name (GIVN) are assigned a 2.
  • A GED viewer uses this data to assemble facts about a root entity. I will explain root entities more when I get to XREF.
  • Here are examples of all the fact codes in my database, grouped by roots, facts, and subfacts.
  • Roots - It's my opinion all root entities should be nodes. Seth has proposed, and I agree, that even locations (PLAC) should be considered for nodes.
    • INDI - Individual record
    • FAM - Family record
    • OBJE - Media Record (Can also be a subfact of other records)
  • Facts - These could easily be part of a node table rather than have this overly complicated subfact structure necessary in a line based system. I will explain more in the final proposal
    • NAME - Full concatenated name for an individual
    • SEX - Gender
    • BIRT - Place marker for the birth subfacts section.
    • DEAT - Place marker for the death subfacts section.
    • CHAN - Internal gedcom reference for the last time a record was changed.
    • NCHI - INDI fact denoting the number of children.
    • OBJE - Reference to a root entity media object associated with an INDI. Typically a picture.
    • FAMS - Reference to the root entity family object that the INDI record has a spousal role in.
    • FAMC - Reference to the root entity family object that the INDI record has a child role in.
    • MARR - Place marker for the marriage subfacts section.
    • DIV - Place marker for the divorce subfacts section.
    • FILE - Location of a file
  • Subfacts
    • GIVN - First and middle name of an individual
    • SURN - Last name of an individual
    • DATE - A subfact of birth, death, divorce, marriage, and many other events.
    • PLAC - While this is a subfact of many events, it would make more sense to have this as a node that other nodes referred to in Drupal. This would eliminate the redundancy of many nodes having a unique entry about the same place.
    • TITL - The name of a media object
    • TYPE - Refers to the type of marriage. Example would be religious
• XREF - Sorry for that long winded example. XREF is basically GEDCOM's nid. It consists of a letter and an incremental number. If a line has a depth level greater than 0, it has no XREF. My GED file has three content types according to this structure: I (INDI), F (FAM), M (MEDIA). GED viewers use this XREF to place a container around a set of facts and subfacts, and also to establish relationships. It is interesting to note that 'I' records are never directly related to each other, but only to 'F' records. Likewise 'F' or 'I' can link to 'M', but 'M' never links back to anything. These are all what I call root entities. They have a GEDCOM depth level of 0 and are used in a relationship structure. Currently our relationship structure mimics this, except that we ditch the XREF and use the FID instead by throwing the FID of a line with an XREF into the relationship database, whether it be to it's facts or root relations.
• FACT_VALUE - Very simply, this is the actual data all of these overhead header information is referring to. In a database table, you would have fields which referred to all of these data types, and then your values would go in the fields. Wait a minute... we do have a database... we're just not using it effectively.
• GEDCOM_SOURCE - This is literally the exact verbage of what you would have found in your GED file. This is actually very commendable that we preserve the original file. Though this is another example of redundancy and how holding too tightly to GEDCOM standard is causing this too limp along. Not along have we fully included your GED file, line by line, in our database, we have also opted to use almost exact same format within our translation of your file.

I'm going to try and wrap this section up here, both so I can make my point, and so I can read what Microbe wrote above before going on. GEDCOM compliance is VERY important. But not so important that we need to bas our internal Drupal database structure off of it. We need to be aware of the standards so that we can import GED files. We then need to RESPECT the standard when (and if we ever) we export to a file. Anything we do in between is our business in my opinion. That being said, there is a much more effective way of managing all of this, and I will explain exactly how it will work in my next post.
Thanks,
Jonathan

Microbe,
I'm glad you were wrong about your ability to communicate ideas. You've basically gotten at the root of what I'm trying to say here, except that I'm going to take three posts to say it all. I basically agree, but I will explain in my next post.
Thanks,
Jonathan

This next post will focus on how I believe we should implement the database structure going forward for the Family module. First I will take a short while to explain how Drupal does much of the work already for us. Drupal has three main tables which manage node data for us. Again, most of this is for my own benefit, as I am still learning Drupal. I am not going to explain every field.

The first is the NODE table. This table consists of the following fields: nid, vid, type, title, uid, status, created, changed, comment, promote, moderate, sticky. The things of importance to us are the NID and TITLE. It would be good to not here that we could help solve one of our problems with individual identification by implementing a dependancy on the token module. Much like the audio module provides tokens for titling audio nodes, we could provide an admin option to determine the title format. (Examples would be {Firstname} {Lastname} - {Birthdate} OR {Lastname}, {Firstname} - Child of {Familyname}) Once again, let other modules do the work if we can.

The second is NODE_REVISIONS. This table consists of the following fields: nid, vid, uid, title, body, teaser, log, timestamp, format. The one to note here is BODY. This is where the biography information would be contained.

The third is a series of tables by the name of CONTENT_TYPE_XXXX. I have checked against some custom content types I created for another site. Here is an example of what is in the table for one of them: vid, nid, field_genre_value, field_no_of_members_value, field_class_value, field_base_street1, field_base_street2, field_base_apt, field_base_city, field_base_state, field_base_zip, field_base_country, field_base_other, field_status_value.

What you are looking at is a custom set of fields for a custom content type. All of the data is stored directly in the CONTENT_TYPE_XXXX table. This would effectively eliminate the FAMILY_FACTS table and split it's data into content types for each root entity.

Here are the content types I think should be created by our module: Family Individual, Family Group, Family Event (currently just a subfact such as marriage or birth, would require the event module if we want it to display on a calendar, could be implemented with a CCK datefield), and Family Location. Seth may have a better insight on sources and citations and whether they should be nodes or fields. Media doesn't need to be created by our module, as we could use CCK to refer to any media content that the user desires.

Each content type would have it's own set of fields (fields can be shared among types if they are redundant, such as date). At first we may wish to leave events as fields, just to keep this simple. Before I layout the fields for each type, we should take a look at relationships again.

Remember that in GEDCOM standard, no two INDI records link directly to each other. An INDI should always link to a FAM, which in turn links to all of it's related INDI's. I think we could accomplish this by using one of the following CCK add-ons and modifying slightly to cause a two-way relationship. Relationships to facts would be eliminated as they would be contained directly in the CONTENT_TYPE_XXXX table as a field. Finally, relationships to media could be established as a one way relationship from a family node to a media node using one of these same CCK add-ons. Here they are: Addnode, Enhanced Nodereference Autocomplete Widget, Hierarchical Select Description, Multiselect, Node factory, Textfield Autocomplete.
Finally, here are my proposals for the field layout of each content type:

• Family Individual
  • Title - Concatenation using tokens.
  • Firstname
  • Middlename
  • Lastname
  • Sex
  • Birthdate
  • Birthplace - Reference
  • Deathdate
  • Deathplace - Reference
  • #Children - Calculated field
  • Child of Family - Reference
  • Parent of Family - Reference
  • Media - Reference
• Family Group
  • Title - Concatenation using tokens. Possible a combination of the spouses' firstnames and their lastnames. It would be nice to store this info in a reference field. Possibly autonode?
  • Marriage Date
  • Marriage Place - Reference
  • Marriage Type
  • Divorce Date
  • Divorce Place - Reference
  • Individuals - We could either do a backreference, or just look these individuals up when the node is viewed. (Show all nodes where child of family or parent of family = family group.)
  • Media - Reference
• Family Location
  • CCK supplies support for different countries with address fields. They are too numerous to include here.
  • Building
  • Street
  • City
  • County
  • State/Province
  • Country
  • Media - Reference

I think a picture should be forming here that we'd basically be completely eliminating both of our current database tables. The next thing that needs to be examined, is how much of our existing code is worth saving as we adopt a totally new structure. I think it would be rather courteous of us to complete an export to GED file feature before we make this huge jump. On the other hand, since our current format hasn't really been creating GEDCOM compliant content anyhow, any additions made in Drupal so far would create junk in the output. I'm going to end here for now, and discuss code in my next post.
Thanks,
Jonathan

Oops, i did write a long comment but seems i closed the page by accident, anyway here will be a shortened version as i can't be bother to write it all again.

will we be able to add places without refernceing a location node with the above setup?

i think media should be referenced the other way round - link the media to the person using one of the above suggested modules(i will look at them and check to see which one i think is best and make a vote). if we have one of these as a required module we can include a viewing page that lists all media linked to that family individual.

father / mother should be in the group table not as 'parent of family' in the individual table as they might be a parents of multiple families. this would also mean you would not need a cck module to link the pages which would make things even more complicated than they are currently.

i dont think we need the '# of children' entry either as this could be calculted by doing a query then counting the rows. also this would be hard to update as like you have also said above the parents don't directly link to children.

apart from the above to points i think Jonathan's table structures are a good way to go

GEDCOM export would as u say be a lot of time wasted although we do need to allow people to easily update to the new table version so i think it should be a conversion of the import script in the update script that needs to be run when modules are updated.

finally i think we should port to drupal 6 at the same time as doing all of this. by the time this massive change is done it should have good support from other modules that do not currently have a drupal 6 version.

i think this was all i had said before
Microbe

P.S. noticed that there is an error in that when you edit an individual the title of the node is still what the name was before it was changed, if i then change it again it changes to the first time i changed it rather than the third. its always one behind. didn't think this was important enough to post a new issue as its only reordering the code (i think).

i looked at those modules for use with realting media(images and forums) to family individuals and i have found that it is really good to use either Enhanced Nodereference Autocomplete Widget or Multiselect These do the same thing in different ways so either could be used - i think the autocomplete one is better though for bigger databases though (also if you have multiple people with the same name as it also shows the nid value). I added this field to the image page and put hidden on displaying it.
Then i used a module which you haven't already referenced, Node Referrer. This module creates a list of nodes referenced to a certain node (the node this cck field is added too). I added this to the family_individual node. this then creates a nice setup for easily referencing images and such to family members. i think it is better to have the referencing it this way round because images and other media are probably going to be added more often than new family members.

This module doesn't however display the images as thumbnails so maybe we should create new module very closely based on this module that does.

All this would mean we wouldn't need to worry about media in our database. We dont even need worry about it but just add into our documentation that something like this is a recommended plan of action.

We could use this also link in the locations except the locations being referred to (thinking about this it would be hard to do as it would not link properly into the GEDCOM).

What we really need to do is create a profile that setups the cck fields on drupal install.

Microbe

Thanks for all the good research here Microbe. Before we go ahead with all of this, I'd still like to give Seth and Pfolk a chance to chime in. I'd also like to keep your enthusiasm going here, so I don't want to wait too long. I'm not certain if they're still working on this, so I think two days might be appropriate. In the meantime, I'd like to discuss the module files and how they'd be affected by this new structure. In some cases it may make sense to start fresh. In others, we may wish to recycle bits of code.

Let me review, once again for my own sake. Here's the general Structure that we've discussed so far.

• Nodes
  • Family Indiviual
    • Title - Concatenation using tokens.
    • Firstname
    • Middlename
    • Lastname
    • Sex
    • Birthdate
    • Birthplace - Reference or Static Field (I think we're going to have to make it one way or another. We may be able to combine two CCK filed operations to make it either or. It will likely be tricky. We could also include both. In other words, the page could say, select an existing location (Enhanced Nodereference Autocomplete Widget) or create a new location (Addnode).
    • Deathdate
    • Deathplace - Reference or Static Field (Same as above)
    • #Children - Agree that this does not have to be a field. It definitely can be done on the fly.
    • Child of Family - Reference
    • Parent of Family - Agree that this should be linked from a group node instead. We should still include a link that perhaps brings you to another page, where you can look up a family, and then Drupal will update the Spousal field for that group node. Node referral would display families the individual is a parent of.
    • Media - I agree with the logic that media will outnumber people, hence searching people will be easier. This means that we will have to customize existing media nodes I believe. Media capability should be a sub-module. That way people don't have to have Image or Imagefield installed to use Family.
  • Family Group
    • Title - Concatenation using tokens. Possible a combination of the spouses' firstnames and their lastnames. It would be nice to store this info in a reference field. Possibly autonode?
    • Marriage Date
    • Marriage Place - Reference
    • Marriage Type
    • Divorce Date
    • Divorce Place - Reference
    • Children - Node referral would display children.
    • Parents - Referral to father and separate referral to mother. How to handle same gender couples?
    • Media - Node Referral.
  • Family Location - See comments above about having static entries in the Individual Nodes.
    • Building
    • Street
    • City
    • County
    • State/Province
    • Country
    • Media - Reference
• Menu Items
  • General
    • /family - Should now be a view.
    • /family/tree - can reuse existing code for tree display. Some slight alteration for the new structure.
  • Create Content
    • Family_Individual
    • Family_Group
    • Family_Location
  • Tabs
    • View - Needs a link on individual for linking to a family group. All other display factors should now be handled by the fields.
    • Edit/Create - Required Fields?
    • Tree - Tab for viewing the ascendancy or descendancy of an indivual. Same as /family/tree, but easily accessible from any individual. We'll need to pick a default of ascendancy or descendancy, unless we have a separate tab for each.
  • Admin
    • Permissions - Standard Drupal permissions for viewing, creating, editing, and deleting nodes.
    • Privacy - The functions can be recycled a bit for this. EstimateDates.inc places a large role in this.
    • Import
    • Export
• Files
  • common.inc - HAven't looked much at this. I'm assuming a lot of the concatenation functions resided here. Much of it may be deprecated.
  • EstimateDates.inc - Can reuse for privacy.
  • family.info - This is version specific I believe.
  • family.install - We may as well just write this from scratch, unless we are going to do a conversion. In that case we will need to follow the standard Drupal convention of database updates.
  • family.module - This is mostly going to be rewritten, but we can use it as a template.
  • group.inc - unfortunately, I think this is not necessary anymore.
  • import.inc - This can be somewhat reused. We may as well create an export.inc when we get to this.
  • individual.inc - Same as group.inc.
  • source.inc - This was Seth's baby. We can keep it, but perhaps not include it until we hear input.
  • tree.inc - Minor modifications?
  • view.inc - A lot of this is going bye bye.
• Dependencies
  • Token
  • CCK
  • Views
  • Enhanced Nodereference Autocomplete Widget or Multiselect
  • Node Referrer
  • Address
  • Addnode
• Finally - Priorities
  1. Nodes
  2. Menus
  3. CCK Profile
  4. Permissions
  5. Views
  6. Lineage Graphs
  7. Import/Export (I think there's no use in having one without the other)
  8. Privacy

I think we can have a functioning module by #3. Those seem like CORE features. The rest are ADD-ON's IMO. I'm sure I'm leaving things out. Let me know what you think Microbe, especially about the order of taking on these tasks. 1, 2, 4, and 5 are my specialties, as they're not too complex, and I'm very anal about sticking to Drupal standards. I'm also very interested in learning how to create fields through module declarations. All I've done in the past is manually create fields and nodes. And please, anyone else, feel free to offer up opinions. Oh, and one final question... Drupal 5 or 6? If we go with 6, we could be waiting till May for CCK to be available, let alone all of the add-ons that we're going to depend on.

i think you've got most of this sussed out. i think drupal 5 is still the one to go with. we still have about another year before people start to stop using it.

i like you idea for the location addnode.

should there be any media entries? shouldn't they all reside with the media content so they can be added simultaniously - refer to individuals and groups and locations if need be.

could we also add 'related locations' for locations that arn't DOB DOD or marriage but are associated with the individual e.g. houses they lived in.

yes, it would only be minor modifications for the tree.inc file - alot of what it does is use other functions so they would be easy to change. however, i feel the hook functions might be best to redoo almost completely only keeping the current ones as a template rather than just editting them. if the family module is going to be really good by the end of this everything needs to use the new implemntations rather than just changing a few things from the old.

how do we create the view of the list of family members whilst installing the module, if you know how to do it that is great.

because alot of the fields we will use will be cck how do we implement them so that we use them but put the data into our own database? is it just like type='nodereference' or similar?

i think maybe privacy should be higher up the priorities because that means people can put their site online early on and the script shouldn't be too hard to change.

it would be nice i think if rather than a tab for the tree there was like a small link in the top right of the page. like ASC - DESC with a little button picture for each. this is just a very minor point though. that will probaly be better answered when we get to implementing it.

permissions should be at the top of our priorities as alot of the priorities are assigned as we go along. we shouldn't spend a long time on them but we should define them and then apply them as we create nodes. i think basically like you said the top 5 items will probably not be in any order but just all come together when they are ready - they all sort of 'require' each other.

how will we deal out things to get this project going? i think its probably best if you create the permissions and all the install files and then everyone who wants to help can work on separate nodes maybe? im not sure how this would work though. alot of the starter stuff needs to be well colaborated and we could end up in a mess if we dont organise it properly.

extra modules that could help that i found:

• CCK Full name - this might be useful to create the proper name structure but its probably easier to do this ourselves rather than using too many required modules
• CCK dates - this could be usefull for implementing a proper sort by DOB or similar function as it would keep it in the correct format. also it would allow proper implementaion of calender, events or timeline modules when we get round to it.

everything else i think is great. lets just wait for some other replies and get started.

forgot to add - can we release a new version as it is with you groups implemented? im sure this would be useful to alot of people and i know you've spent a long time on it so there no point it going to waste.

Quick replies / comments:

should there be any media entries? shouldn't they all reside with the media content so they can be added simultaneously - refer to individuals and groups and locations if need be.

Explain what you meant here. I just want a way for images to display on an individual's page. Just a single image actually. Same for groups and locations. I was thinking the way to do this was node referral. Attach the media from a custom media node and then be able to see it from the referred node.

could we also add 'related locations' for locations that aren't DOB DOD or marriage but are associated with the individual e.g. houses they lived in.

This is a good idea. I'm uncertain on the specific implementation. I'm thinking this is how a Family_event would work. (i.e. Nov 2008, moved to Ohio) We could also try something like image attach. (Location Attach?)

how do we create the view of the list of family members whilst installing the module, if you know how to do it that is great.

Don't know yet. I know other modules do it. It is one of my top priorities. Luckily Views has excellent documentation available.

because alot of the fields we will use will be cck how do we implement them so that we use them but put the data into our own database? is it just like type='nodereference' or similar?

Once again, don't know, but I know that's part of it. I believe you actually have to create the field somewhere in your module. As you may or may not know, CCK field building goes as follows: A module (or other customized code) makes a field type available, you then create a field that uses that type with specified parameters, you then include that field in one ore more node types.

i think maybe privacy should be higher up the priorities because that means people can put their site online early on and the script shouldn't be too hard to change.

I am impartial. Or in other words, sounds okay to me.

it would be nice i think if rather than a tab for the tree there was like a small link in the top right of the page. like ASC - DESC with a little button picture for each. this is just a very minor point though. that will probably be better answered when we get to implementing it.

I still say tabs. There is a hook for it (hook may not be the right word) and it is the Drupal way.

how will we deal out things to get this project going? i think its probably best if you create the permissions and all the install files and then everyone who wants to help can work on separate nodes maybe? im not sure how this would work though. alot of the starter stuff needs to be well collaborated and we could end up in a mess if we don't organize it properly.

Thursday, I will create our final game plan, based on what we've discussed. I'm spending some time thinking about this to get the right attack. If you think you'd be comfortable altering the privacy routines, I'd suggest you start looking at it. Or even better, I'm basically stuck in my efforts to finish the original plan to implement relations under the old structure. If you'd feel comfortable picking that up, I can show you exactly where I'm at and what was giving me the problem. It is basically incomplete as it stands now and wouldn't do anyone a lot of good. It wouldn't be the first time I worked hard at doing something the wrong way, then finally threw it out and did it the right way.

Wow. Views implementation is super easy. There's a views hook views_default_views, within which you paste the exported code from a view. Super simple. CCK implementation seems a little bit more complicated. We may be better off creating the tables we discussed in our own space per node (i.e. family_individual). I don't know. I still need to read up more on this one. I was wrong about other modules. Every module I have installed that creates a node type is doing this through hook_node_info, hook_form, and hook_view. At least Views was good news. I suppose what we could do within our module related to CCK is declare the fields ourselves, rather than having the user have to install all of these dependent field types. More on this later.

to be honest i don't think the cck is a good idea either. it means the are alot of modules that need to be compatible.

• Here are some instructions on declaring the autocomplete fields that would be useful for creating the location entries - they should be quite simple as they only a single variable.
• not sure how to implement the add node though but this is just an extra feature we can add in later on.

i didn't mean work on the privacy quite that quickly - it should be after we have created the install profile and after we have created basic nodes, otherwise there is nothing to test against.

so far no one else has contributed so it looks like it could be just you and me for the time being. i think the project should be 'family tree 2' module that can run along side the current one. no need to work on the transfer odf information at the moment then (dont mean start a new project on drupal just call it that in the .info file so they are seperate).

to-do list

1. Create install file that sets up the database - pyutaros
2. Create all the permissions - pyutaros
3. Create a form that implement create a family individual with all information apart from locations and relations (or leave these in but just as blank fields). - this should implement views variables. - anyonecan create the page but essentially pyutaros has to write the script for saving the data to the database
4. Create a table view that creates a list of all family members, has pager, and is able to be sorted by columns (last two features should implement automatically) - anyone
5. Create a family group page - again anyone can pre-make this page but pyutaros to create saving
6. Create family location page and add to individual page. - anyone hopefully by this point the database will be implemented and anyone can create the save script.
7. Implement privacy script - anyone
8. Implement tree graphs - microbe i know this script already and can update easily adding in the tabs also
9. Create new import and export scripts along with upgrade script (also try and complete import merge). this is the last thing so far as we need to know where every thing in the database is and what other fuctions do before trying to create this no doubt this will be the longest part of all the stages of development - anyone should be a very proficient programmer as this will have NO documentation.

others things like implementing menus for example should be done as we go along

anybody can put there name to a numbered item in the list where it still has anyone written their if they want to contribute. personally i would like to get involved as much as possible but i don't think people can work on this first section simulatneously (creaing nodes and views) so i think it best that either one person does it all or we pass it round (or if there is two of us back and forth) - i have noticed that you always post during my night time so maybe we could in tandem updating at the end of eaches day.
not sure if this would work though? I am going to bed now and my period of free time to spend on drupal is in the last 6 hours (not all though). no point givine times cos im guessing they show differently on ur drupal view as the time is setup differently. if you period of time is after this then we can swap, probably not a good idea though as it would get confusing, see what you think

Microbe,
Let's divide up tasks, rather than pick up after each other. I can be a little sporadic about timing anyhow. I will start yet another branch - 5.x-3.x-dev - so that the previous version will be preserved for reference. I am considering this new version to be completely incompatible with previous versions. I will try and document as I go along in the README. Users will be advised to completely uninstall the old version before installing the new one. I will include instructions in the README on what to check for. I will create the new .install file, .info file, and begin working on the new .module file. I will make the declarations for all three content types at once, but will only do the form for Individual. Once I've got the first content type accepting data and updating the database, I will create the view. I will try and get started on this right away. I'll post updates here.
Thanks,
Jonathan

BTW - I'm in EST time.

I forgot to mention token declaration. That needs to happen before I create the nodes.

Ok so quite alot to do!

Is there anytihng u would like me to do while you setup all the nodes and things?

Sorry for the delay. I think you should be able to get away with constructing the bones of the node view pages. I will be using family_individual, family_location, and family_group for the node type names. The Drupal hook involved with this is hook_view. The branch has been created. You can now download from CVS. .info file now says Family Tree 2.

I had delayed actually completing the .install file until I knew whether the Drupal database abstraction layer was capable of creating tables. It is not, so I will retain the same SWITCH structure it previously had. Good news for porting to Drupal 6. Table creating is implemented in the DBAL for Drupal 6. More updates to come.

Got the first table into the database. family_individual. Also documented each field, though it is mostly self explanatory. It doesn't do anything yet. The new code is still commented out. Here is how the table will be created for MySQL:

Some fields were put in more as placeholders than as functioning parts. They will be easy enough (and exciting for me) to remove with hook_update if we decide.

kool thats quite quick work.
you mentioned creating the view for the nodes - how do we want these to look? should they be similar to how they already are or should they be different? if so how do you think they can be imporved?

oops double posted

The view that we currently have is good, but it doesn't address three things that we have talked about:

1. Multiple descendant families.
2. Media objects.
3. Separate fields for place and date.

For descendancies, we currently refer to the partner as a spouse, but this is inaccurate for unwed partnerships. I like how we currently list the partner, but do we need to include all of their information? Perhaps just their name, gender, birthdate, and deathdate then the list of children. I do like how we currently list the children. We need to add a field in the table for middle name.

The media object would just be a thumbnail of the media that references the person. Off to the side from the person's information. Maybe a look at the audio module would be good here as they show an album art picture next to the song info.

The separate fields for place and date is self explanatory. I can create with a mock up if you like, or if you'd like to make a mock up that would be great too. I will have the other database tables created by the end of the day.
Thanks,
Jonathan

I like your points. i think it should just be name, gender, and group info (marriage, divorce, widowed - this should also be added to the group page as separate field or choose split up type field). i dont think middle names should show of children and spouses on these pages as they make names too long.

Answers to the issues

1. Multiple descendant families.

It does already do this - i have a family on my website where there are two spouses both with children. this works ok apart from one child appears in both sections (checked the database and its correct). but this will probably correct with new databases.

2. Media objects

I think the answer to this is to use node reference on the media pages like i said (e.g. image/forum) and then use a edited node referrer (family media referrer). I will have a look at the audio module and see if i can get a gallery of the images. it might also help looking at image gallery module too. if neither look like they can be used ill create something myself. i have attached what i'm currently doing on my site for media content (or you can view it here: http://familytree.itzalive.co.uk)

3. Seperate fields for place and date

as you said this is obvious and is really easy

i will try creating the form page at the same time and see if it works with the new database

Attachment	Size
related_media.jpg	60.36 KB

Finished the install file. Here is the complete code. It has been committed to development branch 5.x-3.x-dev.

two things:

1. the message you get when uninstalling will be family _group twice as you haven't changed for location.
2. whats changed in the view.inc file - there is a new one uploaded but not sure whats changed

Finished the major edits to family.module today. I think some of the menu items we had before for the nodes were unnecessary. At least api.drupal.org doesn't mention the need for these menu items in node declaration. I have commented out all lines calling for include files for now. I created a new file for locations called location.inc. I also completely wiped group.inc and individual.inc and put a skeleton structure in place that I will fill in as I go. Here is the full text of the node .inc files . I will post the full code for family.modules at the end of this post.

You can see that each node type while be declaring these hooks separately in the form of 'module name'_'node type'_hook. This was specified in hook_node_info in family.module per node type. Also, hook_access was removed from the include files and placed back in family.module as the behavior is the same regardless of node type. The hooks currently in the includes are form, insert, load, update, view, and delete. The only ones that aren't here (and weren't previously) are nodeapi, validate, and theme_node_example_order_info. I'll see if any of these are really necessary. Now that all three .incs exist and most of the structure is in place, we can divide these files up and fill the functions in. I'll go ahead and take group.inc. If you would take individual.inc when you have time, I would greatly appreciate it. That's all for today. All changes have been committed.

@ 29
1) Thanks. Good catch.
2) Not sure. Probably some edits I made in 5.x-2.x-dev. I've been developing from two different machines, and probably hadn't synched up. Either way. From taking a quick look at view.inc, I can tell you that most if not ALL of it will be going away in this new version.
Thanks,
Jonathan

luckily i have already started work on individual (luckily in that i could have done a different page). thanks for the new module file.

i have also noticed that 'deathplace' in the individuals database is written 'deathpace' (no L)
let you know if and when i spot other mistakes

I have found that when the database you using has a prefix the install doesn't use the prefix so doesn't work. this is because you haven't put {} arounf the table name.

also add ? to gender so it can remain unknown as previously or is it just left blank if unknown?

Corrected deathpace to deathplace.
Added {} to all tablenames in install.
Added '?' to gender.

Committed all.

i have done the individual page and some other stuff

1. I have finished (to a suitable extent) creating a family _individual page. This page now setups up a form for all the variables in the individuals table including the ancestor_group column(you might want to move this to the group form but added it just in case). The display should recreate a very similar view to the one it used to including parents and children(i have tested this with putting in some test rows in the database for groups). it also displays multiple spouses (this bit is untested).
2. i have started creating a view for listing all the individuals. it seems to work when it recognizes it exists but this seems to be random. if it doesn't appear in the views list try importing it manually (to test only).
   if you can't see the view it does - same columns as before (lastname, firstname, middlename, gender, birthdate, deathdate) the pager works (i believe) and you can sort it by lastname, firstname, birthdate and deathdate. Any help on getting this to always work would help as i dont know where to go from here.
   also i dont know how to add this view as the menu item so this could be useful to look at too
3. i have updated the tree.inc file to run with the new databases this works fine apart from the formatting for descendants has gone wrong AGAIN. it still runs as a seperate page as i do not know how to initiate tabs. this should be easy to adapt the script itself because there is just a variable for nid that can change to the actual nid of the tab.

i have attached all the files I've changed now as they all have changed slightly (i think).
Pics for the tree are the same as previous release (asctree.png, left.png, right.png center.png, single.png)

Attachment	Size
family.info_.txt	341 bytes
family.module.txt	8.29 KB
individual.inc_.txt	6.61 KB
tree.inc_.txt	10.04 KB
view.inc_.txt	4.82 KB
views.inc_.txt	3.08 KB

Excellent work Microbe. I'm afraid I've fallen a little behind you in my efforts. Hopefully I'll have group.inc completed no later than Thursday. If you start to get really bored, you could tackle location.inc as well. It occurs to me that I don't have all these other PNG files you refer to committed to the 5.x-3.x-dev branch. Could you repost those? Also, would it put you out too much if I put them in a subdirectory? I think the only file we'd have to update is family.module, but I could be wrong. I'll take a look at all those other issues you mentioned upon completion of group.inc.
Thanks again,
Jonathan

Sorry I missed post #27. I agreed with most everything anyhow. As far as media goes... Can we do both? In other words, showing all related media as a list is great. I think it would be cool if we could then select one of those in the list and make it the primary media for the node. What I'm describing might be a feature for down the road. What you have is definitely sufficient. Would we need to implement hook_nodeapi to add the node reference to image node type?

I really like what you've done on your site. I especially like your custom front page. Very cool. Anyhow, just wanted to mention that while I thought of it. BTW do you Skype? Send me info to my contact page if you do. I also have an Ekiga account. (SIP)

One more thought on media, should we dump all the referrals into a table to speed up page load times? In other words, it would definitely be faster to query a table of referrals than to query EVERY media node to see if it references the current node. Let me know what you think.

Oh and one more thing, did you find it was necessary to redeclare hook_access per node type, or is one declaration in family.module sufficient?

I also noticed in individual.inc the following lines (Sorry for the continuous BTW's):

Just wanted to see if it was intentional.

Okay, last BTW. I committed all of your changes to CVS. I finished group.inc's hook_form. I pretty much copied your code and customized for my fieldset. One thing that we are not doing yet I believe is that we are not "tokenizing" <== My made up word. I plan on implementing that after the node types are complete. The point of including tokens is so that node Title concatenation goes into the hands of the user. In other words, if they want {firstname} {lastname} or {lastname} {birthdate} or {firstname} {middlename} {lastname} {birthdate}, all they have to do is enter those tokens in the Title (actually title_format) field. This is definitely something we can implement after the fact. Also, declaring tokens will help us play nice with Pathauto, which many folks choose to use. Anyhow, here is the code for family_group_form. I'm obviously struggling with how to describe a union without calling it a marriage. Also, when looking over the divorce (separation) section, it occurred to me that we don't cover the scenario of death in marriage. Maybe we should also have a field of divorce_type. Thanks again for your work. The dev tarball is finally available here. NOTE - It only updates once every 12 hours.

Okay group.inc is mostly completed. All hooks have been implemented. I started on the theme functions, but that took me into view.inc, and that made my head start spinning. I trudged through 3 levels of callbacks and decided midnight was not the time to start this task. Here is the code from group.inc, followed by what I added to view.inc. I'm sure if you download these files from CVS, you are going to get massive errors about calls to undefined functions. Also, I implemented hook_load in a slightly different fashion. All this code has given me many ideas on how to change things here and there (like using vid instead of nid, implementing token functions to build names), but I'd rather get a working prototype before I start tweaking. If you or I can get this View function completed, I think we'll be well on our way to completing that. Without further ado...

And now View.inc

:( my computers getting slow as this page is way too long!

did you get the e-mail's i sent you yesterday? i think i sent three. replying to your posts above and including the skype name and pics for tree. i also included a quick form for location and implemented your form for group (i also did what you've done above but looking at them i think yours will probably work better) i didn't do any of the view functions though. in your script above though you need to include a db_query in the update and insert hooks for saving the title (it doesn't do it otherwise)

also the title_format needs to be created and saved in these hooks as it is need to display the list on the individuals form. i just did something like:

i tried an update script but it keeps running out of memory on the database i'm testing it on, which only has about 80 individuals, so i gave up. i will create the location view and you can do the group view if you want. i think location values (e.g. birthplace) should have an to check if they are a number and if so use it as an nid tag and create a link with the correct address. i will give this a go and send you any results.

for saving the title also add

i found otherwise it doesn't actually show the title on the page itself

Guys,

I went on your site, and I think the work you have done is fantastic.

I am new to Drupal, but plan to add your family module. I have questions about how I was going to implement your family module:

1) I wanted to create a family for one particular user. So the user will be entering in info for his family, and the fields of the members I am mostly interested in are name, sex, year of birth. Is that possible to change the admin config for Family to only require these values to be entered by a user?

2) Is there a way to create a module that lets the user select a proxy for his family member (say a user acting for his 50 year old mother by selecting her in a drop down menu)? Or would this be easier done by hard coding the html page (although I prefer to stay within the Drupal model itself, hence a module). You will see why in #3 & 4. And where would you save this proxy information, in a php session variable, cookie, sql db?

3) when posting images and forum posts and blogs, is there a way to tag (via token, taxonomy, or active select) these media elements with the proxy's info. So if the user enters a blog, it would be tagged with "female" and "50"?

4) acting as the proxy (eg, again for the 50 yo woman), can the user search and retrieve forum, blogs, groups, etc, with a filter for the proxy's info (age and sex)? So the user will be shown only events or topics which are age-appropriate for the proxy (eg, events which other users have tagged as for those who are 45-55 and female)? And then the user could switch back to himself (or another family member) and the data from forum and blogs would switch accordingly?

Thanks for your help,

George

subscribe

George,
some attempted replies to your questions.

1. If you are meaning can you set it so the user can only edit people they are related to hence being his family. then this cannot be set yet. it is quite hard to do as it requires confirmation of who the user is and then the user needs to be checked to see if its a relation when loading the page.
   this is on our list of developments to make but it is quite hard to achieve. however it would be simple to add a permission for editting the pages they have created like for the node module if this is what you want.
   No fields are 'required' fields as family individuals you might only know there name or there dob.
2. When you select who the user represents in the family tree then it does not related any other information to them. e.g. date of birth, real name. those are seperatly added fields for the user. you can choose to represent any living person in the tree (someone without a death date, so they are not neccersarily still alive). however this currently says 'Me' when linking to the individual so maybe it should be changed to the name of the individual the user represents? or maybe there should be a token to display say what to display in each users profile. the individual the user represents can be changed at any time so you could you use this as a proxy? not sure ehy you would want to be able to be a proxy of someone else though as the proxy wouldn't change any privacy settings as this is user role based.
3. not sure what you mean by this. but i think you should just use taxonomy if you want to create a list of searchable and sortable tags
4. again not sure quite what sure what you mean. to link individuals with images and forums i have used a combination of CCK node reference on the image/forum pages with node refferer on the individual pages. however i dont think this is searchable. but the related 'media' is listed on the individuals page.

these arn't particualaly good answers as what i think you are trying to achieve requires a combination of other modules as well.
if any of the suggestions i have made sounds like they could be the answer post back and i will see if i can implement them into the module.

Microbe

Reviewing this page and seeing all work you guys have done is great. I didnt see this when I posted my request for assistance. I realize now that you have not worked on the import function. Do you have any idea when that will be done? That part is pivotal to my recreating my site. I had previously used PDF reports so that I could share information with my family but I dont want to have to retype everything. So I can import GEDCOM data, that would be great. Thanks again for all the effort you have put into this. I can tell you it is very much appreciated.

Marcia

Sorry I forgot to add that if you cant import GEDCOM files maybe there is a way to use the node import module to bring the information. I tried to do that but could not map the fields.

Marcia

I don't believe the node import will be possible. I'm checking with microbe to see if import is enabled yet. If not, it will be our next step.

node import uses CSV but GEDCOM has its own, more complicated, structure. import still currently doesn't work :( i will have a look at it over the next week if pyutaros thinks that is the best thing i can do to help. :)

Since the redesign is completed, I am closing this issue and will open a new one to document progress on import for 5.x-3.x, which has already started.

oops

Automatically closed -- issue fixed for two weeks with no activity.