Re: [Gramps-devel] export

[Don A. <don...@co...>]

Benny,

I plan on writing a email/document on the new strategy later today (when
I have a bit of time).

But in a nutshell, the goal is not to have any data specific options in
the exporters at all. They will always attempt to write all data.

Instead, we will use the Proxy Databases to provide all the processing.
This way, options can easily be applied to all exporters at once,
without the exporters having to worry about filtering, privacy, or
anything else.

So, as quick responses to your list:

1) This is a good idea. In fact, I want all exporters to be even more
   common - provide a base class that all exporters derive from, so that
   the calling sequence is identical for all exporters. This will avoid
   some of the gymnastics that you have to do in the Export Assistant.=20
   You will just call the exporter without special options.

2) This should not be necessary. The PrivateProxyDb will handle this for
   you. The exporter will get what it expects in a Db, but in reality=20
   this will be a PrivateProxyDb, which will handle all the privacy
   filtering for you. You will see a normal db, but the proxy will=20
   filter out all private data as if it never existed.

3) This should not be necessary. The LivingProxyDb will do this for you
   in the same manner as the PrivateProxyDb

4,5) This will be handled by the FilterProxyDb. The user will be able
   to specify filtering of any type, but your exporter should not have
   to worry about this.

I am also creating a generic ExportOptions class to handle the
interface, which should be standard across exporters. However, if an
particular exporter needs a special interface it can derive from the
ExportOptions.

I'll expand on this later. I should also be in IRC for a short while
today as well.

Don


On Sun, 2007-08-26 at 12:27 +0200, bm...@ca... wrote:
> Don,
>=20
> I want to avoid some double or wrong work.
> Having finished the export assistant, I want to start doing the export op=
tions
> for the .gramps format, but I see you started coding things up for writeg=
edcom,
> and see on chat you want to expand that to all export options.
>=20
> As not to walk over your feet, let me sketch what I wanted to implement f=
or
> .gramps, and you can tell me if I should wait, or what I can do while not
> interfering with your stuff.
>=20
> Here's my list:
>=20
> 1/ move GrampsDbWriteXML.py into WriteXML.py, as effectively writing XML =
is now
> a plugin, and not anymore the core. (Correct yes, we only allow the famil=
y tree
> manager on grdb's or was that not yet completely decided)
>=20
> 2/add 'do not include private option' for .gramps
>=20
> 3/add 'restrict living' option for .gramps
>   I see you did the suboptions away. Note that event descriptions and not=
es
> (also the notes in the sources) can contain the name, and should be left =
out of
> the export. I suggest the one restrict living to be the one with all 3
> suboptions of old exporter incorporated.
>=20
> 4/two checkbuttons:
>     0 Person based export
>     0 Filter based export
> The person based would use a person filter, and then output all other obj=
ects
> related to these persons, so only media attached to these persons, ....
> The Filter based export, would take a filter for every main object, and o=
utput
> everything according to these filters, with reference objects (eventref,
> sourceref, ...) only if both objects are present.
>=20
> 5/ input fields for filter of person, event, source, place, media, reposi=
tory
>=20
> Note that probably filters can be made to obtain the 'Person based export=
'
> purely with 'filter based export', but I presume that to be too difficult=
 for
> aunt martha.
>=20
> 6/ media export? Did not decide yet. For .gramps I was thinking it to be =
ok to
> have the same path as is stored in the database. I see you did away with =
the
> file renaming in the GEDCOM export for now.
>=20
>=20
> Why the above setup? The following two exports I would like to have:
> a) allow ouput of all places and repositories, noting else. This is an id=
eal
> database to start a new family tree of another family.
> b) allow output of everything connected to a certain source.
>=20
> Let me know how I should proceed.
>=20
> Benny
>=20
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Gramps-devel mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel