By John Finlay
PhpGedView attempts to follow the Model-Control-View (MCV) architecture. The goal of an MCV architecture is to separate the data model, the business logic, and the user interface from each other. This means that you donít have business logic in your presentation or your data model and that your presentation can operate completely independent of the data model.
The Data Model
The foundation of the data model is the GEDCOM 5.5 specification. You can find the most recent version of this specification online at the following URL:
Diagrams of the GEDOCM 5.5 data model can be seen at the following URLs:
The GEDCOM specification defines several records such as INDI, FAM, and SOUR which reside at level 0 in the file. These level 0 records are parsed from the Gedcom file into PHP array structures. These array structures are then indexed in a serialized index file, or in SQL database tables. One of the fields in these arrays keeps a copy of the original Gedcom record as it was parsed from the file. This allows for the greatest compatibility and ensures that no data is lost during the Gedcom file import. To further improve performance, an in-memory record cache layer is used to reduce the number of database queries. In fact, the record cache is simply the unserialized version of the index files. So in index mode, everything is running on the cache, while in SQL DB mode, the cache is built-up as the scripts run.
The SQL database model is composed of five main tables: pgv_individuals, pgv_families, pgv_sources, pgv_other, and pgv_users. The pgv_individual table holds information for level 0 INDI records. The pgv_families table holds information about level 0 FAM Gedcom records. The pgv_sources table stores information parsed from level 0 SOUR records and the pgv_other table catches all other level 0 records (eg. NOTE, REPO, and OBJE) that are not stored in the other tables. The pgv_users table contains all of the information about PGV users and is not parsed from the Gedcom file. This database model is illustrated below in Figure 2.
The Control Layer
The control layer provides an API through which you can access the data from the Gedcom. A JavaDoc style reference of this API can be found online at http://www.phpgedview.net/devdocs/api/
Before any data is sent to the UI, it must first pass through privacy checks. These privacy checks determine what the user at the UI has can access based on privacy settings established by the site administrator.
The User Interface is sent out to a client browser in rich dynamic HTML. One of the goals of the PhpGedView project is to try and give the user more information on the screen at a time, so that they can get at more data without losing their current context and without many clicks.
We make the UI even more interesting through CSS which allows themes to be defined. Through the themes, site administrators can completely change the look and feel of the site without modifying the code.
The following table show the different user levels in the PGV system and what they have access to:
There are currently two methods of online editing. The first is through HTML forms at the UI layer. The second is through Web Services at the control layer. Any changes to the data are made at the bottom GEDCOM layer of the architecture stack in the actual Gedcom file. They remain at this level until they are reviewed and accepted by another user. When changes are accepted they bubble up into the database and index file layers.
For more information about online editing see http://www.phpgedview.net/editing.html
Copyright © 2009 PhpGedView Team Members