Rookie question that I'm not having much luck with. In my e4 RCP application, I have a couple of instances where I create an object in a wizard that should then appear in one of my views.
The desired behavior is similar to how the eclipse Package Explorer View updates after a new project is created.
I was thinking I could just grab the view from the partService and run my own update method:
MPart ingredientsView = partService.showPart("com.personal.recipes.part.ingredientsview", PartState.ACTIVATE);
IngredientsView iv = (IngredientsView) ingredientsView.getObject();
iv.updateView();
While this works in other places, when called from a wizard 'partService' is null and the app NPE's out.
So what is the proscribed method of forcing e4 views to update after modifying their contents?
EDIT:
I tried to use the ContextInjectionFactory like #greg-449 showed in his answer, but I'm uncertain where to place it in my code, or how to define the context. I'm launching the wizard from a toolbar button, and placed the following code in my handler:
#Execute
public void execute(Shell shell) {
IEclipseContext context = EclipseContextFactory.create();
IWizard ingredientWizard = ContextInjectionFactory.make(IngredientWizard.class, context);
WizardDialog wizardDialog = new WizardDialog(shell, ingredientWizard);
wizardDialog.open();
}
However, when I tried to get the part service with #Inject EPartService partService; I got an InjectionException saying no error was found.
Once injection is available, using the EventBroker looks like the way to go.
enter code hereThe best way to update a view is to use a model for the content of the view. Your wizard seems to allow editing or creating ingredients. When you perform the finish of your wizard you are probably modifying some ingredient data. The ingredient model should be informed of these changes. If the view uses a content provider that observes this model is will update automatically when the model sees the update (this is the observer pattern).
How this works depends on the nature of your data. You could use the PropertyChange-Support in Java.
To do so let the content provider implement the org.eclipse.jface.util.IPropertyChangeListener interface and fire property change events when the data is changed.
UPDATE
My ContentProvider implements the property change interface. Whenever a property change event is received the viewer is refreshed(asynchronously). All my persistence operations are handled by data managers similar to Fowler's the table data gateway pattern but sometimes for more than one table. The data manager fires the property change event. This way the UI (wizard) does not need to know about persistence
Injection is only done on objects that the application model knows about. So it is not done on Wizards or Dialogs unless you do it 'manually' using ContextInjectionFactory when you create the dialog:
IWizard wizard = ContextInjectionFactory.make(YourWizardClass.class, eclipseContext);
WizardDialog dialog = new WizardDialog(shell, wizard);
This will do injection on your wizard class giving you access to the EPartService.
You could also use the 'event broker' (IEventBroker) to broadcast an event to anything that is interested rather than finding your specific view.
Related
In my application I have a menu which open a SelectionDialog, this dialog is used to choose an object.
When this object is selected I have to display it in the view.
What is the best way to update my view?
Currently, I call myview.update(object) after the dialog is closed (in the handler of the menu). But I think this solution is not well design.
I have read about update my model and notify my view but my model does not change (no data are changed, I only display different Data ).
Does anyone has some ideas for a well design solution ?
Define model listener ( dataPopulated(Event e))
Make your view implement model listener and register it with the Model.
Define a Model class that can contain the objects that you want to populate in the view
When Model.setInput(Object input) is invoked fire dataPopulated() event on all registered model listeners.
Above steps works properly when you have view activated. You need to consider cases like when if view is deactivated or not visible ( make sure you refresh view is visible else you will have unnecessary overhead of refreshing view though it is notvisible)
Try adding a selection listener in the view and register this selection in the dialog.
In the listener action, add the code to show the selected object.
I need to create dynamically buttons in main toolbar. I found a solution, but I can create just one button (dynamic contribution item - class extending ContributionItem). But I need to create more than one button, but I cannot find the solution.
I'm fighting with task to create plugin, which parses a XML file containing structure of menu and toolbars. We've already done this plugin for Visual Studio. Its quite easy in principle, but I found swiftly, that not for Eclipse. There is one small but critical otherness. Plugins are implemented declaratively in Eclipse. The file plugin.xml is the gist of plugin's infrastructure, Java code is just ancillary.
The customer wants to refresh the menu and toolbar whenever the selected project is changed. Eclipse lacks several features needed to get the task done. Main menu and main toolbar are cteated at Eclipse's start-up and then they can be hardly rebuilt.
In the most cases the conditions defined at enabledWhen/visibleWhen elements are sufficient to filter contributions according to the context (active part, selected object, whatever else).
If you need to have more freedom, please try E4 ToolControl that allows you to implement your own UI elements:
#PostConstruct
public void createControls(Composite parent) {
//your custom code here
}
More details here https://www.vogella.com/tutorials/EclipseRCP/article.html#toolcontrols
From my understanding you want to have different buttons on the main toolbar depending on the selection of the project explorer (eg. 1 project is java project, the other is javascript etc.). First you will have to contribute to the main toolbar. I think there are some tutorial available so google will help.
The main steps are:
1. create a command (org.eclipse.ui.commmands)
2. create a handler (org.eclipse.ui.handlers) with the previously declared command id
3. contribute to the main toolbar (org.eclipse.ui.menus) with menucontribution and commandId with the following locationURI: toolbar:org.eclipse.ui.main.toolbar?after=misc
showing/hiding, enabling/disabling a menu item/button also can be done declaratively or "mixed". Declaratively means eg. using enabledWhen/visibleWhen...
Mixed means using property tester (org.eclipse.core.expressions.propertyTester). With this you can define your "enablement logic" in Java code.
In Eclipse e4 the UI is generated from a, EMF based, model. The Application.e4xmi serves as a base for that model. Contributions to the model can be done via fragments, which are again XML, or via processors. Processors are written in Java and use e4 services, like the part service, to modify the model at runtime.
I think you want to write a processor that parses your custom XML and modifies the eclipse e4 model accordingly.
With the MVVM pattern, how does one go about dynamically binding
an ICommand to the click event of a hyperlink inside of a
RichTextBox?
It's a few steps to get there, but you can do it.
You have to use a bindable rich text box, rather than the one that comes with WPF which is not something you can bind. Details here: http://michaelsync.net/2009/06/09/bindable-wpf-richtext-editor-with-xamlhtml-convertor
Once you have that, you'll have a Rich Text Editor that you can bind to a FlowDocument in your ViewModel.
When your FlowDocument is created, hookup a handler for the Hyperlink.ClickEvent in your ViewModel:
Here's the call that adds the handler to the FlowDoc
TheDocument.AddHandler(Hyperlink.ClickEvent,
new RoutedEventHandler(HandleHyperlinkClick));
//Here's the handler definition
private void HandleHyperlinkClick(object sender, RoutedEventArgs args)
{
Hyperlink link = args.Source as Hyperlink;
//...
}
This is the only thing I've ever seen done. FlowDocuments are a little strange because they are sort of a data type and sort of a visual element so in some sense it feels wrong to have it reside in your ViewModel, but this is the way to go.
You find a lot scenarios where it is not possible to use wpf data binding. In these scenarios you can create a new control (e.g. inherit from RichTextBox) and provide the missing dependency properties so you can use data binding.
However, creating a new control to handle simple scenarios is inefficient. It's not forbidden to implement code in the View's code behind file and this makes often more sense than creating a new control.
A concrete example how this can be done is shown in the ViewModel sample of the project:
WPF Application Framework (WAF)
http://waf.codeplex.com
I have a plugin which contains class A that brings up a view defined in class B via the following line of code:
(VideoLogView) PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().showView("Videolog.VideoLogView");
What I need to do in the createPartControl() method of the view (class B object) is access a method in the class A object.
How can this be done?
Thanks.
Look like you are facing the classic issue of "how do I pass arguments to my view" ?
This thread illustrates it best:
I was facing the same problem at the beggining of my RCP project. I was getting weird about the fact that there was no way to pass an argument to a view as the viewed model.
Why? Because (emphasis mine):
You are on an opened, pluggable platform.
You contribute to existing developments, others should be able to contribute to yours.
Therefore you will not "pass" arguments to a view, this would lock the whole thing into a non-opened design.
Instead, your view will ask the platform (or will listen to the platform) to determine which information to manage.
Other views (from other plugins that don't yet exist) might also want to manage the same information on the same event.
What you should do then is to ask the workbench for the current selection. I guess your view is opening on a double click action or simple selection so the object you want to manage in your view will be currently selected.
This is how you could retrieve the workbench selection from your view :
ISelection s = this.getSite().getWorkbenchWindow().getSelectionService().getSelection();
where "this" is a ViewPart.
Then you have to make your initial view (the one initiating the view creation from a given event like DoubleClick) a selection provider. A JFace viewer is a selection provider, so you can use it if you're using jface, or you can implement the ISelectionProvider interface when you're using custom SWT controls (that was my case).
The article "Eclipse Workbench: Using the Selection Service" can also give you some pointers.
I'm a beginner with Eclipse RCP and I'm trying to build an application for myself to give it a go. I'm confused about how one actually goes about handling model objects. None of the examples I can find deal with the problem I'm having, so I suspect I'm going about it the wrong way.
Say I need to initialise the application with a class that holds authenticated user info. I used my WorkbenchWindowAdvisor (wrong place?) to perform some initialisation (e.g. authentication) to decide what view to show. Once that's done, a view is shown. Now, that view also needs access to the user info I had earlier retrieved/produced.
The question is, how is that view supposed to get that data? The view is wired up in the plugin.xml. I don't see any way I can give the data to the view. So I assume the view has to retrieve it somehow. But what's the proper place for it to retrieve it from? I thought of putting static variables in the IApplication implementation, but that felt wrong. Any advice or pointers much appreciated. Thanks.
The problem you are facing here is in my opinion not RCP related. Its more an architectural problem. Your view is wired with business logicand!
The solution can be done by two (common) design-patterns:
Model-View-Controler (MVC)
Model-View-Presenter (MVP)
You can find plenty information about this in the web. I am going to point a possible solution for your particular problem using MVP.
You will need to create several projects. One is of course an RCP plugin, lets call it rcp.view. Now you create another one, which doesnt make UI contributions (only org.eclipse.core.runtime to start with) and call it rcp.presenter. To simplify things, this plugin will also be the model for now.
Next steps:
Add the rcp.presenter to the
dependencies of rcp.view (its
important that the presenter has no
reference to the view)
Export all packages that you are
going to create in the rcp.presenter
so they are visible
In rcp.presenter create an interface
IPerspective that has some methods
like (showLogiDialog(), showAdministratorViews(User user), showStandardViews(User user))
Create a class PerspectivePresenter that takes IPerspective in the constructor and saves it in an attribute
In rcp.view go to your Perspective, implement your interface IPerspective, and in the constructor create a new reference presenter = new PerspectivePresenter(this)
call presenter.load() and implenent
this in the presenter maybe like this
code:
public void load()
{
User user = view.showLoginDialog(); // returns a user with the provided name/pw
user.login(); // login to system/database
if(user.isAdministrator())
view.showAdministratorViews(user);
else
view.showStandardViews(user);
}
As you can see, the view just creates a reference to the presenter, which is responsible for all the business logic, and the presenter tells the view what to display. So in your Perspective you implement those interface functions and in each one you can set up your Perspective in a different way.
For each View it goes in the same way, you will need a presenter for the view which performs operations and tells the view (using the interface) what to display and passing down the final data. The view doesnt care about the logic. This is also very usefull when using JFace-Databindings (then only bound data is passed to the view).
For example, the WorkbenchWindowAdisor will just create everything that is needed in the application. Other views, perspectives, then can enable/disable menus and so on depending on the data they got (like when isAdministrator you might want to enable an special adminMenu).
I know this is quite a heavy approach, but the Eclipse RCP is designed for big (as the name says rich) applications. So you should spend some time in the right architecture. My first RCP app was like you described...I never knew where to store things and how to handle all the references. At my work I learned about MVP (and I am still learning). It takes a while to understand the concept but its worth it.
You might want to look at my second post at this question to get another idea on how you could structure your plugins.