Design notes for the phpGedView import

Created by: Lester Caine, Last modification: 29 Apr 2010 (07:02 UTC)
This package is currently undergoing a rebuild using the latest version of phpgedview, the notes at my site have disappeared, and I'm not quite sure where they went. The 4.2.2 PGV codebase is now synced with the phpgedview package, and installs - downloads a GEDCOM and provides a few navigation pages. It is probably back to the same level of functionality it had with the PGV3 code and still needs a number of major sections porting to the smarty template structure. But it is stable currently and has most of the user authentication provided by BW now.

Genealogy Management

My current genealogy management is via the phpGedView software which allows a comprehensive way of managing the GEDCOM files created using a range of genealogy tools.

phpGedView 4 updates

The latest builds of phpGedView still did not support Firebird, but at least the enabling of Firebird in Pear:DB actually worked, and then I just had to sort out why the package was not working 'lower case' to the result sets. It turned out that I just had to modify the default setting to give ASSOC and lower case. This gave problems in a number of places where the package was looking for NUM result sets, but ASSOC overrides that. After a little playing the code all seems to be playing nicely with ADOdb in Pear mode, now I can look at stripping the config section and replacing it with the bitweaver opening sections.

Integration with bitweaver

The original plan was to link to phpgedview in much the same way as phpBB, except that a number of differences in the way the applications work conspired against that. The use of links to an already working copy of phpgedview, as with any third party application, is always possible, and then only the management of user login needed to be addressed. However, the same difficulty arises as with phpBB, where the core information is not available, theme and module management is duplicated, and facilities already available in bitweaver are duplicated. Also adding to the difficulty was the inability of phpgedview to handle a Firebird database ( along with postgres ), and extending phpgedview to work into Firebird via the PearDB abstraction layer was just another annoyance.

Porting to bitweaver

Having spent a couple of days playing with Firebird IN phpgedview, it became obvious that the main problems were compatibilities of SQL which PearDB simply does not handle, but which ADOdb has covered properly, and so I simply ported the database schema into a bitweaver package as an attempt originally to simply build the necesary tables. Once that was complete, and I started looking at populating the tables, a number of possible ways forward were presented, but the lack of smarty support within phpgedview ment that a complete rewrite of that code would be necessary, so I started to look at the advantages and disadvantages.

Options provided by integrating into bitweaver

Theme, translation and layout management are all core functions in bitweaver, so simply making this available in the new package removes much of the management that requires. The main problem is that translation has already been completed to a number of languages, but I think that it may be possible to import that work into the bitweaver languages structure since they are all provided by simple PHP arrays.
phpGedView has been expanding a number of areas, which include the media management, but since bitweaver already has a tidy gallery system in fisheye, this duplication seems a waste, especially since there is no automatic management of the different image sizes in phpgedview. So simply switching to use the existing fisheye packages removes the need to port much of the media code.
In the same way as images are managed, research notes can be added, but these are simply links to wiki pages under the bitweaver framework, and the addition of comment management allows an enhancement to the facilities that phpgedview does not currently provide.
Provided that compatibility is mainatined within the table structure, using the report generator and main viewing facilities should not be a major problem.

Main changes being introduced

The main problem that has been identified with bitweaver is the use of php scripts to manage the configuration and security of the gedcom data. While there is nothing wrong with this approach, the move to libertise the management of this data requires that these files are replaced with database tables containing the required settings, but this is simply a different way of accessing the same data, and will be used to built a BitGEDCOM object that has the required information.
In the same way as the gedcom settings are moved to the database, the default and user settings will be replaced with standard bitweaver permissions and preferences.

Upgrade paths

At the current time, the data I am working with can simply be re-imported into the new GEDCOM structure, but there is no reason why the upgrade mechanisim provided by bitweaver could not be used to import existing phpgedview data into the bitweaver version.

Current Status

The installer will build the required tables, and the pgv user table has now been dropped. Currently the login is handled by bitweaver, and so levels of access are managed from that. A group for viewing private data will be sorted at some point, currently only an admin can see that ( I hope ). Downloading a GEDCOM can now be handled via the interface, but viewing it still uses the phpgedview templates.
Next step is to start moving the admin stuff to the bitweaver admin sturcture and drop those interfaces that are not needed once a bitweaver/liberty version is available.
Editing is via pop-up windows, and I am working on a short term fix to keep that and may well retain it later as it does provied a nice feel. Perhaps it can be moved to a liberty generic format.

Reference Information

GEDCOM Interchange standard