Difference between revisions of "Addon:Lxml Gramplet"

From Gramps
Jump to: navigation, search
(Go further)
(Go further)
Line 69: Line 69:
  
 
source: [http://sourceforge.net/mailarchive/message.php?msg_id=28173190 Archive (Oct 02, 2011) on gramps-devel mailing list]  
 
source: [http://sourceforge.net/mailarchive/message.php?msg_id=28173190 Archive (Oct 02, 2011) on gramps-devel mailing list]  
 +
 +
===Database backend===
 +
 +
* [[GEPS_010:_SQL_Backend|DB backend for GRAMPS]]: SQL ?
  
 
===Data transfer===
 
===Data transfer===

Revision as of 09:00, 4 October 2011

lxml gramplet is an experimental gramplet working under POSIX platform(s), which reads, writes, transforms our Gramps XML file on the fly without an import into our database (Gramps session).

Dependencies and file format

Goals

The idea of this experimental lxml gramplet is to provide a way for using basic lxml features with Gramps XML files.

XPath, Xslt, RelaxNG validation, can be used and done by lxml, which provides an API very close to etree ElementTree module from python 2.5 and later.

The experimental lxml gramplet aims to use these lxml features[1] by parsing a Gramps XML file generated by Gramps 3.3.x and to generate an output sample, using open W3C standards (XML, Web design, Web services, etc ...).


[1] see also lxml.objectify

Test it

You can get a copy of this draft from Addon repository:

http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons/branches/gramps33/contrib/lxml

Currently, this addon explores multiple ways. Feel free to modify for your own use.

Go further

Comments on DB API Idea

I was basically approaching it from the leave gen.lib alone and
implement a "fully blown" SimpleAccess-esque solution.

At the moment I basically have a 'DB' object which represents an open
database. This at the moment is populated from a Gramps XML file. This
is then basically stored as lxml.objectify objects. Internally a graph
structure is built to represent the linking inside the database (so
relationships and ref. integrity is made easier).

'DBItem' objects consist of the 'node' data, the basic save/delete
etc... Deleting an event automatically removes all other references to
it (which has caught me out previously).

class Person(DBItem):
    DBTYPE = 'person'

Basically registers an object that 'wraps' a basic DBItem, but
containing useful attributes/methods. So for a person, we can write
attributes such as .birth, .mother, .families etc... etc... It can also
over-ride how it should be saved/retrieved etc...

I chose this approach because it keeps the process incremental. We can
still access the 'raw' data in a DBItem for the stuff I'm not caring
about at the moment, but someone can write a 'Place' class later for
instance.

The DB itself is an xpath queryable object (adds a bit of flexibility
for selections that don't have convenient attributes as of yet).

I'll see if I can get the code example out this week.

Anyway, does this seem a reasonable approach? 

source: Archive (Dec 07, 2009) on gramps-devel mailing list

Database compare and merge

  • GrampsCompare.py, a python script for comparing data in 2 Gramps xml files.

source: Archive (Oct 02, 2011) on gramps-devel mailing list

Database backend

Data transfer

Experimental phase for typeless data entry !

Interface

Web application

  • GEPS 013 describes a web-based application that runs in your browser, and requires a server. A prototype is now on-line at http://gramps-connect.org/ which is running trunk on a sample database (id=admin, password=gramps).