lxml gramplet is an experimental gramplet working under POSIX platform(s), which reads, writes (not the original one; safe read only state), transforms our Gramps XML file on the fly without an import into our database (Gramps session).
- 1 Dependencies and file format
- 2 Goals
- 3 Screenshots
- 4 Test it
- 5 Go further
- 5.1 Bibliography gramplet ?
- 5.2 Collaborative indexes
- 5.3 Clients library for FamilySearch API
- 5.4 Comments on DB API Idea
- 5.5 Database compare and merge
- 5.6 Database backend
- 5.7 Data transfer
- 5.8 Environment
- 5.9 Faceted classification
- 5.10 HTML class
- 5.11 Interface
- 5.12 Performances
- 5.13 Web applications
- 5.14 XQuery
Dependencies and file format
- lxml is a Pythonic binding for the C libraries libxml2 and libxslt. It is known for good performances by using C-level (Cython).
- Gramps XML file format is robust and well documented.
The idea of this experimental lxml gramplet is to provide a way for using basic lxml features with Gramps XML files.
The experimental lxml gramplet aims to use these lxml features 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 ...).
 see also lxml.objectify
- Titles, labels and footer are translated (written on python code).
- Full separation of presentation and content for the generation.
- Local output with custom XML data in buffer and XSLT transformation
- Local output without stylesheet
- View via HTML view
- Pseudo dynamic code generation (xml + xslt = html file)
- Action on surname (sort, remove duplicated)
- Action on place title (sort, enable cross search on place fields)
- Hardcoded list written in python and translated by Gramps into our locale (if translation exists)
- You can get a copy of this simple draft from Addon repository:
- You can also download and install it as 3.4 addon.
Currently, this addon quickly explores multiple ways. Feel free to modify for your own use.
Bibliography gramplet ?
- CherryTree is an hierarchical note taking application, featuring rich text and syntax highlighting, storing all the data (including images) in a single xml file with extension .ctd, which has planned to also implement an integration with zotero content.
- Zim is a graphical text editor used to maintain a collection of wiki pages. All pages you create in zim are saved as plain text files with wiki formatting. This means that you can access your content with any other editor or file manager without being dependent on zim. You can even have your pages in a revision control system like CVS or use a Makefile to compile your notes into a webpage. Any images you add are just image files which are linked from the text files. This means that zim can call your standard programs to edit images. When you embed an image in a page the context menu for the image will offer to open it with whatever image manipulation programs you have installed. After editing you just reload the page to see the result. See also third party contributions.
Clients library for FamilySearch API
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?
Database compare and merge
- GrampsCompare.py, a python script for comparing data in 2 Gramps xml files.
- DB backend for GRAMPS: SQL ?
- Gramps Exhibit and experimental phase for typeless data entry.
- Akara is a platform for developing data services available on the Web, using REST architecture. Akara is open source software written in Python and C. eg, Recollection project for the Library of Congress. See the user guide or screencasts (shockwave flash) , .
- Genealogical user tablet could also provide a portable environment.
- A simple reader with a crossplatform lib: qml, qt4, gtk3, kivy, pyjamas, html5; for generating native apps.
GTK+3 provides an HTML backend that allows GTK applications to run natively within an HTML5 web navigator.
- Alternative interfaces with an experimental gen.lib interface.
- Gramps Mobile Interface for mobile devices.
See Gramps performances for comparison on large datasets between different Gramps versions.
- 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=admin1, password=gramps).
- Gramps-tweet, an Addon mashup between Gramps and Twitter.
- "Or something close to SQL like XQuery so you can do querys on gramps xml database similar to SQL Query. It can works even in internet browser thru plugins. XML is quite self-explanatory. Zorba provide python bindings for XQuery."