Re: [Gramps-devel] Loose Coupling?

[Doug B. <dou...@gm...>]

On Sat, Dec 5, 2009 at 12:07 AM, Doug Blank <dou...@gm...> wrote:
> On Fri, Dec 4, 2009 at 7:35 AM, Doug Blank <dou...@gm...> wrote:
>> Benny,
>>
>> Thanks for the feedback. This sounds exactly like the trade-offs
>> between "loose" and "strong" coupling.
>>
>> On the one hand, we currently have exact control over what loads and
>> where items are placed because we use strongly coupling. On the other
>> hand, if we want loose coupling, we need to be able to solve those
>> issues without relying on coupling. I think we can get a good balance
>> between controlling some parts without having to specify in other
>> files too much detail.
>>
>> What I would like to do is think about how this control could come
>> "bottom up" (in the plugin) rather than "top down" (in the code that
>> loads the plugin). That would allow new plugin types without having
>> strong coupling. (Or maybe you are right... just have a pre-specified
>> default order to get started).
>>
>> I agree: the goal would be for the ordering of Views to be the same as
>> now, but would allow for future, new view types (and for the user to
>> be able to rearrange these).
>>
>> I'll work on that...
>
> Trunk revision 13705 now contains these changes, now with loose
> coupling. Please test this out, and see if this looks robust. The main
> difference is that one can now make up a new view type, and add pages
> to it without having to edit any file other than the plugin you're
> defining. There are currently 13 view types now, so we may want to
> look at Nick's treeview idea for Views sooner than later. I can
> imagine a "Time" view too that might show calendars and timelines...
>
> In any event, these current set of changes include:
>
> - new config "interface.view-categories" that defines the known
> categories, in order
> - if a loaded view cat is not in "view-categories", then it comes
> next, in alphabetic order
> - views now set their category in registration, category = (name,
> translated-name)
> - toolbar shows view *names* (from registration), not title (so you
> can change in registration)
> - should work with gettext and views show in native locale
> - predefined pages should be first; if more, they follow
> - tested with multiple gramplets views, works fine
>
> To add more than one gramplet page, you can put
> anothergrampletview.gpr.py in src/plugins/view/ (has to be there, next
> to grampletview.py) with this in it:
>
> register(VIEW,
> id    = 'grampletview2',
> name  = _("Gramplet View 2"),
> description =  _("The view allowing to see Gramplets"),
> version = '1.0',
> status = STABLE,
> fname = 'grampletview.py',
> authors = [u"The Gramps project"],
> authors_email = ["http://gramps-project.org"],
> category = ("Gramplets", _("Gramplets")),
> viewclass = 'GrampletView',
>  )
>
> Note that it has a different ID from the other gramplet view, and the
> name is used in toolbar. That's all you have to do (and BTW gramplets
> remember what page they came from).

FYI: Two (or more) gramplet pages doesn't quite work completely...
when you close gramps, both pages save their settings in the same
file. That can be fixed fairly easily by saving based on view page
name...

-Doug

> The one item I didn't really like is that category is a tuple of the
> form ("Category name", _("Category name")). Need both trans and
> untrans versions. But I liked that the best of all of the
> alternatives.
>
> Currently, there is no way other than editing the gramps32.ini to
> change the order of view categories.
>
> -Doug
>
>> -Doug
>>
>> On Fri, Dec 4, 2009 at 5:39 AM, Benny Malengier
>> <ben...@gm...> wrote:
>>> 2009/12/4 Doug Blank <dou...@gm...>:
>>>> Devs,
>>>>
>>>> One thing I have come to appreciate in working with Django is its
>>>> consistent use of the idea of "loose coupling". I wasn't real familiar
>>>> with the philosophy before, but when I began to understand it, I
>>>> realized that this is exactly one of the things that Gramps doesn't
>>>> have and has always bothered me. In fact, I would describe Gramps as
>>>> strongly coupled.
>>>>
>>>> The philosophy can be read about in detail in any number of places
>>>> (for example, [1]). In a word: "Coupling refers to the degree of
>>>> direct knowledge that one class has of another." Many people interpret
>>>> this also as "the degree of direct knowledge that one part of the code
>>>> has of another part." A good test of the idea is: how many files do
>>>> you have to edit in order to add new code?
>>>>
>>>> I am currently wrestling with this idea in working with the View
>>>> display code. Currently, we have a plugin category ID for every type
>>>> of view. But loose coupling would suggest that there is no need to
>>>> pre-specify these types; they could be discovered when we load the
>>>> plugins. (This is just an example of loose coupling, but the idea
>>>> could be used in many places throughout gramps).
>>>>
>>>> For example, say that I want to add a new kind of View... perhaps a
>>>> Data Entry view (let's call the view category "Certificates" and the
>>>> view "Census"). Currently, we would have to edit a number of files to
>>>> add the new view type to define and expose this. On the other hand,
>>>> loose coupling says: Gramps doesn't know about view types, and will
>>>> just  define the views as needed. This seems to be a more Pythonic
>>>> approach, and makes extending a project much easier (there are no
>>>> additional files to find and edit).
>>>>
>>>> One downside is that you won't discover a misnamed View type until you
>>>> see that the view is showing up in the wrong place. But this would of
>>>> course be obvious the instant you run the code. Strongly coupled code
>>>> (like gramps currently is) might immediately give an error and crash
>>>> on a mislabeled view (or would just put it in the wrong category) but
>>>> would require knowledge about the view in multiple places.
>>>>
>>>> I'd like to advocate more loose coupling in gramps, but wonder if
>>>> there is resistance to this philosophy, and if so, why. Feedback
>>>> appreciated.
>>>
>>> Well, the code you refer to is like that because we want the user
>>> interface to look a certain way, and hence presets what can be
>>> possible, and presets the order in which views will be shown in the
>>> interface sidebar.
>>>
>>> If you don't need this control, that code can go out, and you have no
>>> more coupling, but I believe we need to guard how Gramps ends up
>>> looking without allowing for plugins to just create some sort of
>>> anarchy.
>>>
>>> So, it is the same as the preset order in the reports or tools menu.
>>> I think things are still logical:
>>> --> plugins/pluginreg.py knows how a gpr.py file defines a view plugin.
>>> --> because we preset the allowed categories, pluginreg.py also
>>> defines this and does not load plugins that are in unknown category
>>> --> gui/grampsgui.py has a function to obtain registered views, import
>>> the files, and order them as we want them for the gramps interface.
>>> --> gui/viewmanager.py uses the API of a generic view to drive the interface.
>>>
>>> I do not see much coupling here, just that we want some control you
>>> would rather have we do not have. It is easy to change the code to
>>> have some predefined categories of views, and then allow for extra
>>> categories behind that as defined in view plugins. We then would still
>>> have the desired control of the interface (show the views we want on
>>> startup in the order of Gramps). Feel free to change the code like
>>> that, so remove the MISC category, create a GRAMPLET category, and
>>> then allow plugins to register to unknown categories, which the
>>> interface code appends to the end of the viewcategories in the
>>> sidebar.
>>>
>>> Note that in the future we would want to add reordering views in the
>>> sidebar, so the control over how the views look like is something we
>>> want for the 'default-out-of-the-box' experience, not something that
>>> users would not be allowed to change (as they could in 3.1.x by
>>> changing the listing in the ini file).
>>>
>>> As an aside:
>>> 1/ I think it would be interesting if you offer in gramps-addons, a
>>> second gramplet view. So the user would download this (it would be
>>> only a gpr.py file) and then the gramplet category has two views in
>>> which gramplets can be shown
>>> 2/ I did not finish the changes yet. What still has to happen: the
>>> view menu must contain a configure option (like the toolbar icon which
>>> I would allow to hide via the preferences), or perhaps a configure
>>> menu with entry for each shown view. The view menu should also offer a
>>> way to switch to another view in the category for those cases the
>>> toolbar is not visible. The column order dialog would move into the
>>> view configuration.
>>>
>>> To come back to the original question, yes, loose coupling is a nice
>>> aim. However, in Gui code you will need some model class that controls
>>> the view, and you will also need API's that other classes then need to
>>> implement. Obviously, API changes lead to a host of changes that need
>>> to be done in other files, I see no way around that.
>>>
>>> Benny
>>>
>>>> -Doug
>>>>
>>>> [1] - http://en.wikipedia.org/wiki/Loose_coupling
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>>>> a free event focused on virtualization and cloud computing.
>>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>>>> http://p.sf.net/sfu/redhat-sfdev2dev
>>>> _______________________________________________
>>>> Gramps-devel mailing list
>>>> Gra...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>>
>>>
>>
>