Sir Mon’s Weblog

Just another weblog

Lichauco Family Tree

Right now, the canonical Lichauco Family tree is a Work in Progress.

I’ve got basic descendant charts going at: but even that needs a lot of work. Clicking on the root box brings you up the tree. Clicking on the lower boxes makes that person the new root and regenerates the tree. So far the responsiveness has been snappy. So I’ll keep this structure right now without any caching. TODO:

  • Add Multiple marriages to level 1 I’ve taken care of handling multiple marriages in the level 0 (root level). But I need to extend this to at least level 1 (children of the root). You can see how this works by going to Macario was quite a guy.
  • Add handling of dupes There’s been a fair amount of intermarriages within the clan. Cousins marrying cousins. Uncles marrying their nieces. The display of this leaves a lot to be desired – the obvious effect is that when viewed from one side of the union, the children are seen, but from the other side, the children are not seen. This to-do is supposed to ensure that the children can be seen from both sides.
  • Honoring tree-hints. Multiple marriages or unions can be distracting and embarrassing. Some marriages carry more weight than others. The user should be able to configure the rendering of the tree to eliminate distracting unions and data while it is preserved in the DB.

This application makes extensive use of the Sitemap.css developed by I’ve seen the way does the “family” type presentation but I rather like mine better. It’s more compact and lends itself more to large extended families. In subsequent posts, I’ll expound on the data model used for my angkan software.

December 24, 2009 Posted by | Uncategorized | , , , , , , , , | Leave a comment

Open Source and Configuration Files…

I’m writing some family tree software which I’m GPL/Open Sourceing. It’s the angkan project in Sourceforge.

While developing, I use a directory for running programs and thus I require real DB credentials. I don’t want to commit these credentials to an open source repository but the size of the project does not warrant a deployment script (yet). Thus, if I were to use the same directory as a repository root for svn, I would be compelled to make the DB credentials generic.

Taking a cue from the way WordPress retrives configuration files, I’ve come up with the following.  I create the config file with the REAL credentials in a directory ABOVE the repository root, while the one in the repository root contains GENERIC credentials. The REAL config file contains just the defines. The config file in the repository root contains code which runs the REAL config file if it exists.

The directory structure will be something like:

+ public_html
+ REAL_ConfigFile
+ project directrory (svn root)
+ GENERIC_ConfigFile

In GENERIC_config.php, prior to setting the db credentials, it first checks to see if a site specific file REAL_config.php exists in the directory above (which will not be committed into the source tree) and if it exists, it “includes” that file. If not, then some default db credentials will be used which can then be cusotmized by those using the software.

For instance a good config file will be something like the following:
if (file_exists( dirname(dirname(__FILE)) . ‘/REAL_config.php’ )) {
require( dirname(dirname(__FILE__)).’/REAL_config.php’ );
} else {
// put default db credentials were
define( ‘HOST’, ‘localhost’ );
define( ‘DB_NAME’, ‘changeme’ );
define( ‘DB_USER’, ‘changeme’ );
define( ‘DB_PASSWORD’, ‘changeme’ );

There may be more elegant ways to do this. But I thought I’d share this particular technique.

December 23, 2009 Posted by | Uncategorized | , , , , , , | Leave a comment