GEPS 013: Gramps Webapp

From Gramps
Revision as of 11:41, 14 October 2009 by Dsblank (talk | contribs) (Overview)
Jump to: navigation, search

Many Gramps users would like to collaborate or share their genealogy data on the web. This GEP describes a webapp, a web-based application that runs in your browser, and requires a server.

Motivation

The main focus of a Gramps-based webapp is collaboration. The Gramps webapp will allow users to easily move their genealogy data to the web to be seen, and possibly edited, in a collaborative environment.

Here is a small list of goals:

  1. Create a fullscale GRAMPS web framework
  2. Allow multiple users via the standard web browser
    1. Users will log in and have various levels of permissions
  3. Build on GRAMPS codebase and wealth of resources
    1. Reports
    2. Tools
    3. Visualization
  4. Use standards and well-known, well-tested frameworks where possible
    1. WSGI protocol for running code
    2. Django framework

Overview

The Gramps webapp is written in Django. Django is a sophisticated, modern web development framework. It is written in Python, albeit in a very different style from Gramps. However, part of the motivation of Django is that it breaks up web development into very clearly defined parts following the Model-View-Controller paradigm.

The webapp uses pre-existing CSS created for the "Narrated Web" report.

Here is a screen shot from the main page of Gramps in Django:

Gramps in django.gif

Getting Started

Getting Started with Django and Gramps

The Gramps webapp (and Django in general) is broken into three well-defined parts: models/views, templates, and CSS. The models define the tables and relationships, but this is done in Python (not SQL). The models also define the API to read/writing/editing the data. The views are also written in Python, and are closely tied to the models. The templates are written in HTML and a template language that is very easy for non-programmers to use and understand. Finally, CSS is just Cascading Style Sheets, where all of the graphical definitions are made.

Let's take a look at specific examples of each of these.

Here is the model that defines Person from src/gen/web/grampsdb/models.py:

class Person(PrimaryObject):
    """
    The model for the person object
    """
    gender_type = models.ForeignKey('GenderType')
    families = models.ManyToManyField('Family', blank=True, null=True)
    parent_families = models.ManyToManyField('Family', 
                                             related_name="parent_families",
                                             blank=True, null=True)
    references = generic.GenericRelation('PersonRef', related_name="refs",
                                         content_type_field="object_type",
                                         object_id_field="object_id")

Here, you can see that Person only has 4 parts: gender_type, families, parent_families, and references. There are are properties, but they are shared with other PrimaryObjects.

The big difference here is that the Person class defines the Person table, and the interface to it. Most Python code would probably have Person be an instance of a class, but Django uses classes to represent many things.

Here is a template from src/data/templates/person_list.html:

{% load my_tags %}
<table cellspacing="0">
<thead>
  <tr>
{% table_header headers %}
  </tr>
</thead>
<tbody>
  {% for person in persons.object_list %}<tr class="{% cycle odd,even %}">
    <td>{{ person.gender|escape }}</td>
    <td>{{ person.first_name|escape }}</td>
    <td>{{ person.last_name|escape }}</td>
    <td>{{ person.email|escape }}</td>
  </tr>
  {% endfor %}
</tbody>
</table>
{% paginator %}

Templates define what to display.

Concurrent Edits

Concurrent access for write and read imply several problems when people by accident change the same objects at the same time. GRAMPS itself has an elaborate signal handling for cases when dialogs are open with no longer current information. In a web environment, this becomes more difficult however. This is not built into Django.

For discussion on this issue in Django, see:


Example GMS Web Sites

Genealogy Management Systems on the web:

Note here: the intro page is a collection of gadgets/controls, which then link into the real data.

Django

A prototype of a GRAMPS Django webapp is in branches/geps/gep-013-server. To run it, do the following:

  1. Download Django. I'm running version 1.0.3
  2. Checkout the branches/geps/gep-013-server from SVN
  3. cd gep-013-server/src/gen/web/
  4. Edit settings.py
    1. Edit the path to the Sqlite DB
  5. make
  6. make run
  7. Point your webbrowser to:
    1. http://127.0.0.1:8000/
    2. http://127.0.0.1:8000/admin/


Concurrent Edits

Concurrent access for write and read imply several problems when people by accident change the same objects at the same time. GRAMPS itself has an elaborate signal handling for cases when dialogs are open with no longer current information. In a web environment, this becomes more difficult however. This is not built into Django.

For discussion on this issue in Django, see: