2013/5/22 Nick Hall <firstname.lastname@example.org>
On 22/05/13 19:36, Benny Malengier wrote:This is what the census editor does at the moment. It means that you would have to write a different "save" script for each certificate type, and users would only be able to define new sub-types.
Well, keep in mind that I always have birth and death certificates in mind, not census. I'm ok with xml for defining the fields, but what to store based on this is better in a python module we can easily debug in my opinion. Over generalization is nice for programmers, but difficult for a project as Gramps to maintain. So I rather not describe in some xml what code should do, let's just write code.
Yes, you could generate a different input form based on the same xml definition.
Now you have input in column form, we could easily provide two possibilities: one the column entry, the other one line in the column in editor form on a notebook, with new tabs for every line in the column entry. Some certificates work best in one form, others in the other, but they are 1-1 mapping, so one xml to define them (Note that for twins you have two birth cert at the same time, so birth cert needs option of more than one also).
The problem I have in the census addons is that we use Gramps attributes to store values. We want the key to be human readable and not a code. The human readable attribute is stored in the xml.
Next is translation. Things like census.xml better have not
but instead a key, with a value added to the key which is translated. So, I now see,
attr_text = _(attr.childNodes.data)
But it would be better to have a map
attr_text = _(attr2en[attr.childNodes.data])
which translates Relation to the English Relation. In this way, <_attribute>Relation</_attribute> could be <_attribute>Rel1</_attribute>
instead, and errors in column name and such don't change keys later on.
attr2en can be defined in the xml itself, or in python, not sure what is best. I we want users to be able to write extensions, the first I suppose.
I understand, but a Dutch user does not want Occupation in his attributes, he wants the Dutch "Beroep" stored. For Occupation no problem probably as it is perhaps an existing type, but for other columns it might.
In python tradition, I don't propose to have actually rel1, but instead something readable, just that rel1 should work just as good. English is not something special, rel1 needs to be translated to a language, be it English or another. This mapping can be in the xml itself, I would just prefer it explicit, instead of implicit as now.
It is nice to be able to see all the attributes in the event reference editor. At the top attributes tab you can see the values for the person (columns), in the shared event section attributes tab you can see the values for the event (headings).
At present, the census report reads these values.
Are you proposing that we don't copy attributes into the event and event reference objects from the certificate object?
No, I'm proposing to store it in the certificate object, and if user generates data from the certificate, to store it in the event/ event reference or other object too depending on what is fitting for the certificate. What is stored in the objects can be different from what is in the certificate though.
Eg, a person could write
Name: Nick Hal
if it appears like that in the census, but then connect this to person Nick Hall.
So a censusline would actually probably be: column, value, handle
where handle is the object where data of that censusline is stored after generation. Perhaps even a bit more complex, as a line can lead to a person object, or an attribute of a person.
For census we have census event, so logical to store there values. For birth certificate, we normally only store source and birth event, but birth event is not when the certificate is actually written, so it makes no sense there to add what is stored in a birth certificate in the birth event.
The census xml uses the <longname> tag for tooltips in the editor and column headings in the report. We could separate them and have a <tooltip> tag.
A tooltip entry in the xml would be nice too.
Yes, this will work. In fact I have some experimental code that uses the same approach. :)
In my proposal, type would be census for a census event, subtype UK1901, ... .
The subtype can set different attributes, but the type defines how certificate data will be stored. I suppose some columns are required, like Name in census.
Is anyone actually thinking of doing this?
All in all, I think it is doable, but a good GEP has to be written, and we must agree on it, as once implemented, we need to keep supporting it.
I'm itching, but I estimate more work than I have time for :-(