export

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

export

bm-5
Don,

I want to avoid some double or wrong work.
Having finished the export assistant, I want to start doing the export options
for the .gramps format, but I see you started coding things up for writegedcom,
and see on chat you want to expand that to all export options.

As not to walk over your feet, let me sketch what I wanted to implement for
.gramps, and you can tell me if I should wait, or what I can do while not
interfering with your stuff.

Here's my list:

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 family tree
manager on grdb's or was that not yet completely decided)

2/add 'do not include private option' for .gramps

3/add 'restrict living' option for .gramps
  I see you did the suboptions away. Note that event descriptions and notes
(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.

4/two checkbuttons:
    0 Person based export
    0 Filter based export
The person based would use a person filter, and then output all other objects
related to these persons, so only media attached to these persons, ....
The Filter based export, would take a filter for every main object, and output
everything according to these filters, with reference objects (eventref,
sourceref, ...) only if both objects are present.

5/ input fields for filter of person, event, source, place, media, repository

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.

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.


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 ideal
database to start a new family tree of another family.
b) allow output of everything connected to a certain source.

Let me know how I should proceed.

Benny

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: export

Don Allingham
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.
   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
   this will be a PrivateProxyDb, which will handle all the privacy
   filtering for you. You will see a normal db, but the proxy will
   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, [hidden email] wrote:

> Don,
>
> I want to avoid some double or wrong work.
> Having finished the export assistant, I want to start doing the export options
> for the .gramps format, but I see you started coding things up for writegedcom,
> and see on chat you want to expand that to all export options.
>
> As not to walk over your feet, let me sketch what I wanted to implement for
> .gramps, and you can tell me if I should wait, or what I can do while not
> interfering with your stuff.
>
> Here's my list:
>
> 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 family tree
> manager on grdb's or was that not yet completely decided)
>
> 2/add 'do not include private option' for .gramps
>
> 3/add 'restrict living' option for .gramps
>   I see you did the suboptions away. Note that event descriptions and notes
> (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.
>
> 4/two checkbuttons:
>     0 Person based export
>     0 Filter based export
> The person based would use a person filter, and then output all other objects
> related to these persons, so only media attached to these persons, ....
> The Filter based export, would take a filter for every main object, and output
> everything according to these filters, with reference objects (eventref,
> sourceref, ...) only if both objects are present.
>
> 5/ input fields for filter of person, event, source, place, media, repository
>
> 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.
>
> 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.
>
>
> 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 ideal
> database to start a new family tree of another family.
> b) allow output of everything connected to a certain source.
>
> Let me know how I should proceed.
>
> Benny
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> -------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: export

bm-5
Great!

This will give me time to code on the event code instead (TYPE, ...). Glad to
leave it in your expert hands.

Note about 4/

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

it will be important that the exportoptions class gives an understandable user
interface. My suggestion of two checkboxes (person based versus all filters)
fit's in that category.

I just checked in two new filters based on work of Joachim Breitner
that fit in
this idea. One gives all events that are attached to persons matching a person
filter (also included as husband/wife of family event).
This can be generalized to other objects, and give general filters on
which the
FilterProxyDb can work:
-> filter A of persons
-> filter of families containing persons in filter A
-> filter on sources connected to persons matching filter A
etc.
This general way of working however will make exporting powerful, however, it
also means it will be slower! I would nevertheless go for this approach.
I could start making the extra filters needed for this to work.

There is a problem however common to export: eg what to do with people in to
export families that are not in the to export person filter.
I suppose on export, you obtain the family, it is in the family filter (which
checks the person filter for all of its members to determine this), so you
obtain the handle, but on asking the father handle, you only get
something back
if father is in person filter.
It is great if the filterproxydb does this, but it looks like a lot of
overhead,
so the performance will be hit compared to export now. Again, I would
nevertheless vote for this general approach.

On how to handle media file paths and possible copying to a dir of
media files,
is another thing the exporter will need extra logic for which is however also
common over GEDCOM and gramps export.

Benny


Quoting Don Allingham <[hidden email]>:

> 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.
>   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
>   this will be a PrivateProxyDb, which will handle all the privacy
>   filtering for you. You will see a normal db, but the proxy will
>   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, [hidden email] wrote:
>> Don,
>>
>> I want to avoid some double or wrong work.
>> Having finished the export assistant, I want to start doing the
>> export options
>> for the .gramps format, but I see you started coding things up for
>> writegedcom,
>> and see on chat you want to expand that to all export options.
>>
>> As not to walk over your feet, let me sketch what I wanted to implement for
>> .gramps, and you can tell me if I should wait, or what I can do while not
>> interfering with your stuff.
>>
>> Here's my list:
>>
>> 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
>> family tree
>> manager on grdb's or was that not yet completely decided)
>>
>> 2/add 'do not include private option' for .gramps
>>
>> 3/add 'restrict living' option for .gramps
>>   I see you did the suboptions away. Note that event descriptions and notes
>> (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.
>>
>> 4/two checkbuttons:
>>     0 Person based export
>>     0 Filter based export
>> The person based would use a person filter, and then output all
>> other objects
>> related to these persons, so only media attached to these persons, ....
>> The Filter based export, would take a filter for every main object,
>> and output
>> everything according to these filters, with reference objects (eventref,
>> sourceref, ...) only if both objects are present.
>>
>> 5/ input fields for filter of person, event, source, place, media,
>> repository
>>
>> 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.
>>
>> 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.
>>
>>
>> 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 ideal
>> database to start a new family tree of another family.
>> b) allow output of everything connected to a certain source.
>>
>> Let me know how I should proceed.
>>
>> Benny
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>> -------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: export

Espen Berg-2

...this is just a test...

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel