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.
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?
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.