Templates are used to describe ''what'' to display. Here is a template from [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/src/data/templates/main_page.html?view=markup src/data/templates/main_page.html]:

+

Templates are used to describe ''what'' to display. Here is a template from [http://svn.code.sf.net/p/gramps/code/trunk/data/templates/main_page.html data/templates/main_page.html]:

<pre>

<pre>

Revision as of 19:02, 27 January 2013

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.

A prototype is on-line at http://gramps-connect.org/ which is running trunk on a sample database. You can log into the site, as a:

Contents

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 edited with proper login and permissions, in a live, collaborative environment.

Here is a small list of goals:

Create a fullscale Gramps web framework

Allow multiple users via the standard web browser

Users will log in and have various levels of permissions

Build on Gramps codebase and wealth of resources

Reports

Tools

Visualizations

Date and calendar functions

Translations

Manual and documentation

Use standards and well-known, well-tested frameworks where possible

WSGI protocol for running code

Django framework

Underlying powerful database engines

FAQ

1. Aren't there already many fine, web-based genealogy programs? Why don't you just use one of those? Aren't you re-inventing the wheel?

There are indeed many fine, web-based genealogy programs, and some are even free software/open source. However, there are a few good reasons to develop a Gramps-based webapp:

Gramps has hundreds of thousands of lines of code, some of which could be re-used directly in a webapp. For example, the reports could be run and downloaded directly from the webapp.

Gramps has a very well-defined set of tables and relationships that could be re-implemented for on-line use.

Users have grown to appreciate the design of Gramps, and we want to continue to build on this design.

Many users want to collaborate. Currently, they would either have to move their data in and out of Gramps, or give up Gramps completely.

We want to keep the developers and users that we have, and so not splinter our groups. By building the webapp on top of core gramps code, we continue to refine and make better our current code, and keep our current developers working on the parts that they know and love.

2. Why do you need a web framework like Django? Can't you just use the same Python code, and same database that Gramps already uses?

We can't use the same database (what is called a "backend") directly. Currently Gramps uses BSDDB, and it is not configured for use in a multiuser, client/server environment. But even if we could use the same backend, we would still want some type of web development framework. Django is one of the best in any language, and it just happens to be in Python.

3. How easy will this be for me to use on my website?

We have designed it to be as easy as it can be, given that we are using Python. Many web sites allow Python programs, and Django allows many different variations in running. We picked the protocol with the most availability (WSGI). Don't worry if you haven't heard of it. Your webserver can probably run it.

4. When is this going to be available?

We are hoping to have a fully functioning webapp ready for testing July 2010.

5. How can I help?

You can start by reading the rest of this page and sending ideas and comments to the Gramps-developers mailing list, and running the code if you can.

Overview

The Gramps webapp is written in Django. Django is a sophisticated, modern web development framework. Django is written in Python, albeit in a very different style from Gramps. However, part of the motivation of using Django is that it breaks up web development into very clearly defined parts following the Model-View-Controller paradigm. Two of these parts require no special programming knowledge, and thus will allow more people to be able to possibly customize and participate in the Gramps project.

The Gramps webapp (and Django in general) is broken into three well-defined parts:

models/views

templates

CSS (Cascading Style Sheets)

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. The webapp uses pre-existing CSS created for the "Narrated Web" report of Gramps which was used for created static web pages. Let's take a look at specific examples of each of these parts.

Here, you can see that Person only has 4 parts: gender_type, families, parent_families, and references. There are additional properties, but they are defined in the PrimaryObject class which is shared with other tables. Here is PrimaryObject:

The big difference here between typical Python programming 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.

The first retrieves all of the rows for the Person table; the second retrieves just the one record that has the unique, primary key 1, and the third retrieves the single record that has the unique handle of 'gh71234dhf3746347734'. Note that we never connected onto a database... Django is (currently) define to connect on to one database, and it does it on import. The database is set in src/webapp/settings.py.

An alternative method of interactively talking to the database is to use manage.py:

The double-underscore in the keyword "gender_type__name" of the filter method is a Django convention. It means "replace wth the correct syntax". If Python allowed it, it would be written as Person.objects.filter(gender_type.name="Male") but that is not legal syntax.

Here is an overview of all of the models and how they are related:

To see more graphical representations of the data, run "make docs" in the src/webapp/ directory, and then look in src/webapp/docs/.

This will export your regular Gramps BSDDB data into whatever Django database you have defined in settings.py above. You now have your data in a sqlite SQL database, and can access it via the webbrowser.

To import data back from Django's SQL table back into Gramps from the website:

Create a file named "import.django" somewhere (just needs to end in ".django").

Roadmap

Phase 1: get the basic Django skeleton in place, including the core HTML templates, models, views, and templatetags. Should be able to browse the 8 primary tables. Get translations in place. Goal for version 0.1 to be announced with Gramps 3.2 in March 2010.

Phase 2: Be able to run all of the reports directly from the web with an option interface. Be able to import/export from the web. This will largely depend on a gen/db/dbdjango library. Goal for version 0.5beta, May 2010.

Phase 3: add and edit data from the web. This would complete the functionality of the web interface. Goal July 2010.

Phase 4: Refine and polish. Release with Gramps 3.3.

If you would like to work on an area, please note it here:

Kathy - edits and adding new data

Doug - Integration with gramps core; browsing data

- Translation system

- Proxy interface to show Private data

- concurrent edits

- date widget

- running reports interface

- media files... where do they go?

- options interface, for editing options to run report

- import GEDCOM from web

- full djangodb.py to replicate all functions of bsddb

- user support (email, mailing lists, permissions, etc)

Issues

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.