Re: [Gramps-devel] Patch for exporting witnesses to Gedcom file format

[Bastien J. <bas...@m4...>]

I'm willing to help, but my OO python skill are quite limited.... (I am
used to object oriented c++ though)
So I cannot come up with the design, but once you have decided on this, I
will be happy to help. [Since I really want to be able to export as much
data to GeneaNet]

Cheers,
Bastien

On Fri, May 25, 2012 at 12:42 PM, jerome <rom...@ya...> wrote:

> Maybe I see what you mean: it will something close to what is currently
> used by localized handlers (date, relationships).
>
> So, I think I can understand basics of overload idea, but the registering
> process is a little bit fuzzy (__init__ ? , options ? , set into user
> preferences ? , etc ...).
>
> We could have something like:
>
> from export import register_gedcomhandler
>
> class CustomGedcomWriter(GedcomWriter):
>
>    def abcdef:
>        """
>        pass over self(abcdef) from GedcomWriter class
>        """
>
> leave empty if there is no need to customize.
>
> If this works, then maybe we could also have the same type of extension on
> import?
>
> Despite I can test it and it, and despite we had already generated for
> localized handlers, to generate this sub-classes environment might still a
> little bit too much for myself... How to register this third-party addons
> and the use of this 'overload' option?
>
>
> Jérôme
>
>
>
> --- En date de : Jeu 24.5.12, Doug Blank <dou...@gm...> a écrit :
>
> > De: Doug Blank <dou...@gm...>
> > Objet: Re: [Gramps-devel] Patch for exporting witnesses to Gedcom file
> format
> > À: rom...@ya...
> > Cc: "Bastien Jacquet" <bas...@m4...>, "gramps-devel" <
> gra...@li...>
> > Date: Jeudi 24 mai 2012, 17h53
> > On Thu, May 24, 2012 at 11:33 AM,
> > Jérôme <rom...@ya...>
> > wrote:
> > > Gramps 2.0.x was able to select different output via a
> > target selector!
> > >
> > > "Target
> > >    While GEDCOM is a standard, not every program
> > implements it in the same
> > > way. This can lead to data loss. GRAMPS can reduce the
> > data loss in some
> > > cases. You can tell GRAMPS what program is the target,
> > and GRAMPS will
> > > customize the exported file for that program. If your
> > program is not listed,
> > > choose the "GEDCOM 5.5 Standard"."
> > >
> > >
> http://gramps-project.org/gramps-manual/2.2/en/ch03s05.html#gedcom-export-fig
> > >
> > > But this was a nightmare for maintenance!
> > > Nobody had time to test all versions of programs into
> > this target list and
> > > to look at all these custom behaviors.
> >
> > But we are not talking about going back to the old way with
> > options
> > and interspersed hacks inside the core libgedcom. Instead we
> > are
> > talking about a third-party plugin that just has the options
> > for these
> > GEDCOM extensions, and associated overloaded methods for
> > reading/writing the relevant sections. It will be up to them
> > to test
> > and maintain the addon.
> >
> > -Doug
> >
> > >
> > > Jérôme
> > >
> > > Doug Blank a écrit :
> > >
> > >> On Thu, May 24, 2012 at 10:06 AM, Bastien Jacquet
> > >> <bas...@m4...>
> > wrote:
> > >>>>
> > >>>> Doug's suggestion:
> > >>>>
> > >>>> "I don't have any comment on correctness of
> > such Gedcom extensions, but
> > >>>> just a suggestion that someone could make a
> > 3rd party addon that
> > >>>> extends our Gedcom importer/exporter. Such
> > an addon could collect all
> > >>>> of the common extensions used by a group
> > (of a particular product, or
> > >>>> from a particular culture) implementing
> > some defacto extension
> > >>>> standards." --2012-05-19
> > >>>
> > >>> Well, why not, but I clearly see that as more
> > time-consuming. And I dont
> > >>> see
> > >>> how we could reuse current gedcom export
> > without dirty code interleave.
> > >>> [would inheriting from the gedcom exporter help
> > ?]
> > >>
> > >>
> > >> I don't think that would be more time-consuming.
> > Yes, the proper
> > >> manner would be to inherit from the classes in
> > libgedcom. The code was
> > >> written (it appears) for just this purpose. You
> > will probably need to
> > >> extend the exporter and the importer to keep these
> > extensions in sync.
> > >> In the long run, it will be very clean to be able
> > to look at a single
> > >> file and manage such GEDCOM extensions going into
> > .ged files, and
> > >> coming out of them.
> > >>
> > >> If you have any trouble, or need help getting
> > started, I'm sure there
> > >> are many developers willing to assist.
> > >>
> > >> -Doug
> > >>
> > >
> >
>