Re: [Gramps-devel] report and tool api

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

On Wed, January 16, 2008 7:51 am, Brian Matherly wrote:
> Benny,
>
>> > Brian, Benny, and I have been looking at this code
>> and the related code in
>> > Reports to come up with a better API for
>> registering plugins, and creating
>> > the instances. It isn't clear yet what direction
>> to go, and it still
>> > works, but a new registering/instantiating
>> mechanism should be on the list
>> > of things to explore over the next year.
>>
>> Well, what is needed to move the decision forward?
>> The more I am using the registering code, the more I
>> am in favor for a
>> dictionary with defined keys to register reports,
>> tools, as you mentioned in
>> a bug report somewhere.
>> Brian was opposed for reasons I don't remember.
>> Some extra keywords to be able to create the tool
>> and report menu's
>> independently from the category might be
>> interesting?
>
> I think you are confusing two topics. The menu
> organization is not really related to the fact that
> the report system is tightly coupled and many classes
> suffer from low cohesion. If you changed the menu
> structure, the code would still be difficult to read
> (or worse).
>
> Refactoring the code is a long term effort. I have
> been slowly refactoring the report system over time. I
> have a large change in my working copy right now that
> will further improve it, but I want to wait until
> after 3.0 Beta.

A good discussion on some of these issues is in the tracker:

http://bugs.gramps-project.org/view.php?id=1310

and there is a GEP:

http://www.gramps-project.org/wiki/index.php?title=GEPS_005:_Enhanced_Plugin_Interface

The Menu Options are getting involved sooner than later due
to the evolving API, however. I had to change the way that
options_class was called---this is getting really ugly. See:

src/PluginUtils/_Tool.py around line 92

>> > > ***************************
>> > > For future consideration...
>> > > ***************************
>> > >
>> > > I may be jumping to the wrong conclusion here,
>> but I guess that there
>> > > are _not that many_ dbstate instances around at
>> any one time. Passing
>> > > that data around is largely equivalent to having
>> a global variable.
>> > >
>> > > A longer term goal might be to untangle class
>> interdependencies so that
>> > > such intimate coupling can be avoided. Of
>> course, that's *hard*.
>> > >
>> > > If dbstate is, in fact, largely equivalent to a
>> global, it may even make
>> > > code cleaner (easier to maintain) to create
>> global, and avoid all the
>> > > passing. OTOH, that may invite further increase
>> of coupling within new
>> > > code. <sigh>
>> >
>> > I think I would continue to keep dbstate a
>> parameter for the time being.
>> > It would be harder to add it back in, later, for
>> places that need its own
>> > dbstate.
>>
>>
>> There is one dbstate in gramps (DbState.py) and one
>> uistate (DisplayState.py),
>> both contained in the viewmanager. However dbstate
>> can change it's db, that
>> is dbstate.db refers to one unique database path. So
>> yes, those never
>> change. A CLI program would need a dbstate only.
>
> Actually, a CLI program shouldn't need dbstate. It
> should only need a database.
>
>> Is dbstate hence not the controller object and is it
>> in that IT model
>> (sorry, I read those books 15 years ago) not normal
>> the objects have a
>> reference to it? Solving that via global var is not
>> something I have seen
>> before.
>
> Global variables for dbstate and uistate would not be
> appropriate because there are plenty of areas of code
> that should not have access to them (plugins being
> one). What we really need to do is decouple the code
> more so that there is a clear line between code that
> needs dbstate and uistate, and code that does not.
> Then it wouldn't need to be passed around so much.

Thanks Jim, Benny, and Brian, for the questions and discussion.
I'm still learning all of the requirements for this part of
GRAMPS. Don't some plugins need dbstate, and uistate? More
discussion on the decoupling would be useful for me.

-Doug

> ~Brian
>
>