Re: [Gramps-devel] new method in RelLib

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

Well, to be honest, I'm not thrilled with the cross dependencies. We've
tried really hard to make things as independent of each other as
possible.

Now, that being said, my desire to keep a clean separation isn't
necessarily the most important thing. If it solves a significant problem
that can't be solved in any other way, then I can live with it. But it
would be nice to see if we could solve this in a cleaner manner.

Could we accomplish the same thing with a helper function, possibly in
Utils.py?

def get_source_backlink_handles(db,source):
    .....

So, instead we would get:

  references =3D [ ref for ref in Utils.get_source_backlink_handles(db,sour=
ce) ]

Or, could this be a function of GrampsDbBase?

  references =3D [ ref for ref in db.get_source_backlink_handles(source) ]

Don

On Mon, 2005-12-19 at 13:52 +0000, Richard Taylor wrote:
> Hi
>=20
> I have added a new method to PrimaryObject. I have added a=20
> get_backlink_handles() method. This uses the new reference_map to get all=
=20
> backlinks for a given PrimaryObject. For instance to get all the backlink=
s=20
> for a Source.
>=20
> references =3D [ ref for ref in source.get_backlink_handles(db)]
>=20
> This is not particularly interesting but it does break an abstraction tha=
t=20
> RelLib previously maintained. This is because get_backlink_handles() requ=
ires=20
> a database object as a parameter. This introduces a runtime dependency=20
> between RelLib and GrampsDbBase (to be precise, it required an object tha=
t=20
> has a find_backlinks_handles() method with the correct signature). It doe=
s=20
> not introduce a parse time dependency because GrampsDbBase does not need =
to=20
> be imported into RelLib.
>=20
> I think that the dependency is a worthwhile trade off because it allows u=
s to=20
> hide any complexity of how these backlinks are found from the calling cod=
e.=20
> This is good OO abstraction design.=20
>=20
> If people think that this is OK, then we can add some more specific backl=
ink=20
> methods to other RelLib objects. For instance Reference has stub methods =
for=20
> managing Sources that are connected to it but at present the implementati=
on=20
> is in the calling code, it could be moved into the RelLib.Reference class=
 and=20
> make any calling code more simple.
>=20
> A policy decision is needed on this.
>=20
> I have also added a unittest for the new method in the test/ directory. D=
o=20
> people think that these unittest are worthwhile? I always work by writing=
=20
> unittests as I write the code, it is the only way I have any confidence i=
n my=20
> code. But if others don't want these cluttering up the cvs I will stop ad=
ding=20
> them and keep them to myself.
>=20
> Regards
>=20
> Richard
>=20
--=20
Don Allingham
http://don.allingham.org