PhpGedView Architecture

By John Finlay

 

Introduction

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 is built up around the GEDCOM 5.5 specification. The control consists of an API written in PHP that allows access to the data model, privacy filtering, and generation of the user interface. The UI delivered in the view layer is sent to the browser as HTML, CSS, and some JavaScript. Figure 1 illustrates this architecture stack and shows the different PGV layers that make up the MCV components.

 

 

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:

http://www.phpgedview.net/ged551-5.pdf

 

Diagrams of the GEDOCM 5.5 data model can be seen at the following URLs:

http://homepages.rootsweb.com/~pmcbride/gedcom/55model1.gif

http://homepages.rootsweb.com/~pmcbride/gedcom/55model2.gif

 

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 Presentation

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.

 

User Levels

The following table show the different user levels in the PGV system and what they have access to:

User Level	Description
Public visitor	This is a public visitor that has not authenticated by entering a username and password. Default privacy settings do not give them access to the data of living people. They cannot edit data.
User	This is an authenticated user. They will have access to the MyGedView portal and can view private data depending on privacy settings.
Editor	This is an authenticated user who has been given editing privileges. They will be able to edit anything that they can see. Their changes will still need to be accepted by a user with higher access privileges.
Acceptor	This is an authenticated user who has edit privileges, but who can also accept or undo changes into the database.
Gedcom Admin	This is a user who can accept changes and also administer Gedcom configuration and privacy settings.
Site Admin	This user can do and see anything on any Gedcom in the site and can create new users.

 

 

Online Editing

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