|Re: How to deal with two plugins contributing each other [message #766068 is a reply to message #765764]
||Thu, 15 December 2011 07:14
| Daniel KrÃ¼gler
Registered: July 2009
On 2011-12-14 17:32, Behnil wrote:|
>> Simple: Don't do that.
> Well, my client needs it. I used Table and List for simplicity, but in
> fact the first UI plugin visualizes the model in graph and the second UI
> plugin visualizes model in Table.
I just recognize that I misunderstood the sentence to which I replied
that way. You might have noticed that, because both solutions were
intended to realize what you wanted to do.
>> Yes, so why doesn't the first and second UI plugin provide the
>> corresponding "show model in a ..." contribution?
> I don't understand. Those two plugins are independent each other. But I
> think its regular requirement from users to see the model in the table
> and then to open the same model in List (or graph, or something else...).
Well you have not given much context information to us: It was
completely unclear in which way the model plugin would have any
opportunity to provide these "show model in a ..." presentations,
contributions, what ever you meant.
> The situation:
Yeah, would have been great if you would have described the situation in
the first place ;-)
> You are looking at a table showing a model. The table is within an
> dialog which is from UI plugin A. Now you would like to see this model
> in graph (or list in this simplified example)
So UI plugin A has a table with a context menu, and other UI plugins can
extend this - what is the problem with such an approach?
> So you, as a user, expect a context menu item "show this model in graph
> (list)" which would open an dialog with graph (list). This dialog is
> from UI plugin B.
> This one side contribution is easy, because I can create an extension
> point in UI plugin A and let other plugins (B) to contribute theirs
> There would be an interface which contributor would implement
> in theirs contributions.
Here the fuzziness factor increases again: What interface are you
talking about? Why isn't it sufficient to depend here on types from the
> So all plugins contributing to the UI plugin A
> would be depended on that plugin.
I would expect that this is the model plugin, so what is the problem? If
it isn't you should move this dependency to a "base UI plugin" that all
real UI plugins depend on.
> But I also need "show this model in table" in context menu of the graph.
> The graph (list) is shown in a dialog which is from UI plugin B. And
> this is problem.
This shouldn't be a problem, if the mystical interface that you
mentioned above is part of the model plugin. If that doesn't work, it
should be part of a very base UI plugin that you need to supply.
> Because I can't create the same extension like in plugin A and let
> plugin A contribute to it. It would mean the plugin A is depended on
> plugin B and it's forbidden to have cycle dependencies.
Not only forbidden, but just plain bad design, because for non-obvious
reasons UI plugin A has some preferences over UI plugin B.
>> Alternatively your model plugin could provide an extension point that
>> allows other plugins to contribute a "show model in ..." extension. Both
>> UI plugins would register correspondingly.
> I think that model plugin should be just a "stupid"" container for model
> classes. It shouldn't have any UI.
Well, you didn't really explain what you mean in the first place. I
understood your explanation that the model plugin has the responsibility
to show these texts.
HTH & Greetings from Bremen,
Powered by FUDForum
. Page generated in 0.02703 seconds