Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Rich Client Platform (RCP) » How to deal with two plugins contributing each other
How to deal with two plugins contributing each other [message #765718] Wed, 14 December 2011 15:13 Go to next message
Jan Krakora is currently offline Jan KrakoraFriend
Messages: 477
Registered: December 2009
Location: Prague
Senior Member
Hello,

let's say I have a model plugin containing model classes. Then I have two UI plugins. The first one show the model in a table, the second one show the model in a list.

How can I add "show model in a list" to the first plugin and "show model in a table" to the second plugin?? They should be completely independent, so they can't add itself as dependencies.

Thanks
Re: How to deal with two plugins contributing each other [message #765740 is a reply to message #765718] Wed, 14 December 2011 15:44 Go to previous messageGo to next message
Daniel Krügler is currently offline Daniel KrüglerFriend
Messages: 853
Registered: July 2009
Senior Member
On 2011-12-14 16:13, Behnil wrote:
> Hello,
>
> let's say I have a model plugin containing model classes. Then I have
> two UI plugins. The first one show the model in a table, the second one
> show the model in a list.
>
> How can I add "show model in a list" to the first plugin and "show model
> in a table" to the second plugin??

Simple: Don't do that.

> They should be completely independent, so they can't add itself as dependencies.

Yes, so why doesn't the first and second UI plugin provide the
corresponding "show model in a ..." contribution?

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.

It depends much on how you specify what requirements are imposed on
"show model in ...".

HTH & Greetings from Bremen,

Daniel Krügler
Re: How to deal with two plugins contributing each other [message #765764 is a reply to message #765740] Wed, 14 December 2011 16:32 Go to previous messageGo to next message
Jan Krakora is currently offline Jan KrakoraFriend
Messages: 477
Registered: December 2009
Location: Prague
Senior Member
> 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.

> 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...).

The situation:

  • 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 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 actions. There would be an interface which contributor would implement in theirs contributions. So all plugins contributing to the UI plugin A would be depended on that plugin.

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.
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.

> 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.
Re: How to deal with two plugins contributing each other [message #765808 is a reply to message #765764] Wed, 14 December 2011 17:56 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Are the different UI components shown to the user in a view? In an editor?

There are ways to contribute to the menu of a view/editor from a different plugin, depending on how you are showing the different UI components.

PW


Re: How to deal with two plugins contributing each other [message #765823 is a reply to message #765808] Wed, 14 December 2011 18:25 Go to previous messageGo to next message
Jan Krakora is currently offline Jan KrakoraFriend
Messages: 477
Registered: December 2009
Location: Prague
Senior Member
> Are the different UI components shown to the user in a view? In an editor?

They are shown unfortunately in dialog. I know the way to contribute to menu using the org.eclipse.ui.menu extension point. But this is not the situation.
Re: How to deal with two plugins contributing each other [message #766068 is a reply to message #765764] Thu, 15 December 2011 07:14 Go to previous messageGo to next message
Daniel Krügler is currently offline Daniel KrüglerFriend
Messages: 853
Registered: July 2009
Senior Member
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
> actions.

Exactly.

> 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
model plugin?

> 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,

Daniel Krügler
Re: How to deal with two plugins contributing each other [message #766106 is a reply to message #765823] Thu, 15 December 2011 08:32 Go to previous messageGo to next message
Eclipse UserFriend
Hi Behnil,
> They are shown unfortunately in dialog. I know the way to contribute to
> menu using the org.eclipse.ui.menu extension point. But this is not the
> situation.

In my understanding this would mean that there is a third UI plugin
which provides the dialog? Let's call this third plugin C. Why don't you
provide an extension point in C which A and B will extend? Then I
wouldn't do so much trouble with popup menus in plugins A and B. No, I
would provide tabs. In each tab one extension is displayed having the
name "table" or "graph" and the respective visualization of your model.

best regards,
Gilbert
Re: How to deal with two plugins contributing each other [message #766141 is a reply to message #766068] Thu, 15 December 2011 09:18 Go to previous messageGo to next message
Jan Krakora is currently offline Jan KrakoraFriend
Messages: 477
Registered: December 2009
Location: Prague
Senior Member
You are right. My explanation skills aren't excellent. Maybe because English isn't my native language.

> 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?

Thanks to Paul Webster and you it's not problem any more http://www.eclipse.org/forums/index.php/t/266398/

>> 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)

>> 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
> model plugin?

Forget about the context menu and the activeMenuSelection variable (which is the way how can I easily
get the table's selection and do with that in another plugin whatever I want).

Imagine you have to work with entire table and not only with one selected row as a model.
And imagine you can't use context menu. Instead there must be buttons at the bottom of the dialog.
The dialog is from UI plugin A. The buttons are the contributions from other plugins,
one of them could be UI plugin B. So one of the buttons would be "Show this model in graph".

I can easily create extension point in the UI plugin A where other plugins contribute for example a JFace Action class.
This Action class then represents the button. The problem with that solution is how can I pass the model representing
the table to this contributed action classes?
There is where the mystical interface come from. I could create it in the UI plugin A

public interface IContribution {

    public void doWithModel(Model model);

}

and let contributed plugins to contribute implementation of this interface instead of the JFace Action.
There would be an icon and text element for the button in extension point of course.
This way I can easily create all buttons in the UI plugin A dialog for all contribution and when clicked,
call doWithModel() on them appropriately.

But, this means that all plugins which would like to contribute to the UI plugin A, would have declared direct
dependency on that plugin because they would need to access to the interface.

Re: How to deal with two plugins contributing each other [message #766351 is a reply to message #766141] Thu, 15 December 2011 15:43 Go to previous message
Jan Krakora is currently offline Jan KrakoraFriend
Messages: 477
Registered: December 2009
Location: Prague
Senior Member
Hi Gilbert,

> In my understanding this would mean that there is a third UI plugin
> which provides the dialog? Let's call this third plugin C. Why don't you
> provide an extension point in C which A and B will extend? Then I
> wouldn't do so much trouble with popup menus in plugins A and B. No, I
> would provide tabs. In each tab one extension is displayed having the
> name "table" or "graph" and the respective visualization of your model.

No, the dialog is provided by the UI plugin A.
Previous Topic:Can´t export feature based product to multiple platforms
Next Topic:Beginner needs help with RCP and plugin dependencies
Goto Forum:
  


Current Time: Tue Mar 19 10:46:20 GMT 2024

Powered by FUDForum. Page generated in 0.02688 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top