Re: [Gramps-devel] [Gramps-users] GRAMPS Problem

[Douglas S. B. <db...@cs...>]

Benny said what I was trying to say, only much better. To summarize the
main issue, I think it is all about abstraction:

Currently, gramps code requires the developer to know HOW the data is
organized. A more abstract interface would allow the developer to just get
WHAT he/she wants, without regard for the layout of the tables.

Another example:

data = self.db.getPersonData(key)
for family in data["families"]:
   for p in family["children"]:
      print p["primary name"]
   for p in family["parents"]:
      print p["primary name"]

(of course, you don't have to use dictionaries, but the point is that you
should be able to do a lot without ever knowing about all of the handles.)

This would also allow some of the optimizations in other databases to be
used. Rather than iterate over the keys at the Python level, SQL (and
maybe others) can do that in the lowlevel backend.

-Doug

On Thu, January 18, 2007 8:47 am, ben...@ug... wrote:
> Quoting Alex Roitman <sh...@gr...>:
>
> [snip]
>> One can use GrampsDb and RelLib packages of gramps
>> as standalone python packages that are ui-independent,
>> and then write another front end. Today :-)
>
> True, however, the same is not (yet) true for the data/object-model.
> For example: to delete a person: this code is part of _PersonView.py,
> namely in
> method delete_person_response. So the entire logic of deleting a person
> is part
> of GUI code.
>
> This is something I struggle with with the code: larger database logic is
> repeated everywhere, RelLib only contains basic methods, mimicking the
> database
> very closely. Eg
>         family_handle = person.get_main_parents_family_handle()
>         if family_handle:
>             family = self.db.get_family_from_handle(family_handle)
>             ... do something
>
> Why not a get_main_parents() and get_all_parents() method ?
>
> Also, why all the references to db in GUI code. Handle should be just a
> key, but
> for people new to the code is looks like a special thing. I mean:
> p = self.db.get_person_from_handle(handle) in stead of p = Person(handle)
> The methods now allow for more optimized access, but in many cases (and
> for
> plugin writers specifically) this optimization is not really needed.
>
> It probably is just style, and I might be missing something...
> I can copy a lot of code for the plugins I wrote from other plugins, but
> never
> as one single method, always as a group containing some logic.
>
>> But the sober reality is: most of gramps code is
>> about interface and not data access. So writing
>> another frontend is almost like writing another
>> application.
>
> It is about interface, and the logic on how to access the data. In the
> Edit
> dialogs, you need to save, like:
>         trans = self.db.transaction_begin()
>         self.db.commit_media_object(self.obj,trans)
>         self.db.transaction_commit(trans,_("Edit Media Object"))
>
> To use in another GUI, obj.save() would be easier.
>
> Well, just my 2 cents
> Benny
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>


-- 
Douglas S. Blank
Associate Professor, Bryn Mawr College
http://cs.brynmawr.edu/~dblank/
Office: 610 526 601