I'm working on an editor to make changes to a list of emf objects. What I want is every time I modify those emf objects, my editor is to be refreshed to reflect the changes.
The approach I tried before was having a wrapper object over the said emf object (because I don't know how I can or should modify the emf-generated source code) to contain the editor needs to be refresh. The changes will be made on top of that wrapper object, and propertychangelistener is to be dispatched after emf object have been changed. However this solution is very ugly because:
Each object will need to obtain the reference to the editor itself, introducing a reference dependency
Having a separate overlay object like that introduces complication into maintaining the code
What is the right way to do it?
I think of adding binding framework to handle model object changes
You may want to look at following tutorial as a starting point.
http://www.vogella.com/articles/EclipseDataBinding/article.html
Related
I'm investigating some novel approaches to extending openui5.
Particularly I'm playing around with the idea of implementing material design with openui5 (through material design lite https://github.com/google/material-design-lite). Normally, you would extend existing components with new ones, but I want to avoid this if possible.
One approach would be to dynamically change the renderer of a component during runtime. I want to change the renderer for a particular instance of a component and not all instances.
I've found that through the MetaData of the control, I can change overwrite the render function
myComponent.getMetadata().getRenderer().render = function(oRm, oControl) {
...
};
myComponent.rerender();
This gives the intended effect. However, using this approach changes the renderer for all instances of the component class.
Is there some way of only changing the renderer for a particular instance?
Well, in the standard controls that come as part of the framework, the *Renderer for each control is a static class - this is why the control instance is passed in to the render() method. This is why re-defining the render method, as you did it, affects all control instances of this type.
Sneaking into metadata.getRenderer() and returning something different for this instance would cause similar issues, as ElementMetadata is also one instance for the entire control class. Cloning the metadata and modifying it for certain instances would be an option, but I think not a nice one.
Maybe a simple solution is the best choice here?
Mark the control instances to be rendered differently with a flag and overwrite the render method to either do the normal thing or do the special handling, depending on this flag.
Something like this:
http://jsbin.com/yabujigitu/edit?html,output
After a quite long struggle with the known and unfortunately one of the few help articles about controlling properties, tabbed properties etc. (links below), I have decided to ask for your help.
What I need to do seems not that hard, but, well, I just couldn't bring the pieces together. So the problem is:
I want to extend the existing properties view of Eclipse (PropertySheet) with some further tabs, which will be later on filled with certain information from EMF objects, which in the end implement IAdaptable. So they can be queried for PropertySources and there are already a few tabs, sections extended in the corresponding project in its manifest, which are being successfully gathered from the Selection Listener of the PropertiesView.
Here comes the tricky part: I don't need to extend this project further, by defining further tabbed properties in its manifest. I need to implement a seperate plug-in project, which does this extension job for the other main project. I don't need extra views or so. This existing project provides the property sources and like sad has its own designed tabbed property view via its extensions.
I have actually become quite familiar with the concept of the views and properties, I can build some Property Sources and let the Properties View gather/show/manipulate the properties.
But this idea, letting an external plug-in extend the Properties View with tabs of an another EMF-based plug-in project, just can't get to me. I am really confused and don't know with what to begin with.
I would be unbelievably glad, if you could point me to the right direction.
Thanks a lot!
*Links:
http://www.eclipse.org/articles/Article-Properties-View/properties-view.html
http://www.eclipse.org/articles/Article-Tabbed-Properties/tabbed_properties_view.html
I have extended org.eclipse.ui.editors.text.TextEditor to implement a custom editor.
For this editor, I have defined a marker type (org.eclipse.core.resources.markers extension point) and an annotation type (org.eclipse.ui.editors.annotationTypes extension point) to mark specific parts of code in my editor. I use a reconciler to update my annotation model.
Now I want to add a quick fix / quick assist feature. I simply want eclipse, to show a box with proposals, when I hover over an annotated part of the code and replace that part with a given string, when I click on a proposal. Just like the quick fix feature for the java editor.
So, what is the best way to implement this behavior?
I read about marker resolution generators and quick assist processors, but I'm still confused how it all works together...
I would be glad, if someone could point me to the right direction.
EDIT: From what I've understood so far, a MarkerResolutionGenerator is responsible for showing quick fixes in the problems view. To get quick fixes in the source viewer, I would have to set a QuickAssistAssistant for my SourceViewer and implement a QuickAssistProcessor which returns CompletionProposals.
Is this the right way to do it?
EDIT2: I'm wondering if I need Markers at all, or only Annotations, I'm confused...
I finally found out how to get Quick Fix to work for my editor.
I use the annotationTypes extension point to register my own annotation type and the markerAnnotationSpecification extension point to specify the look and feel. In my custom SourceViewerConfiguration class I override getAnnotationHover(...) to return a DefaultAnnotationHover object and getTextHover(...) to return a DefaultTextHover object, so the annotations are shown in my source viewer.
Then I override getReconciler(...) to return a MonoReconciler with my own implementation of IReconcilingStrategy to create the annotations in its reconcile(...) method. And finally I override getQuickAssistAssistant(...) to return a QuickAssistAssistant with my own implementation of IQuickAssistProcessor. The computeQuickAssistProposals(...) method in the processor class computes the quick fix proposals which show up, when I press CTRL+1.
I don't create any Marker objects and don't use a MarkerResolutionGenerator, since the marker concept is much more heavyweight than using only annotations and the functionality which annotations provide fits my needs.
You have to register an extension to the extension point org.eclipse.ui.ide.markerResolution. This extension refers to a markerType (using the markerId), and also a resolution generator.
The latter component is responsible for calculating the possible fixes: it reads the marker, it can check the related files, etc., and creates marker resolution instances. These resolution instances basically process the erroneous files, and hopefully fix the original problem.
During marker resolution, you should not worry about removing the markers, as after the fix is executed, sometimes the validation would run again (e.g. during the build, or if no automatic validation is available, then manually - but it is not the task of the marker resolution to update the list of markers).
I tried to create a properties view for a graph model in an Eclipse RCP Application. The graph elements are from a non-eclipse library and so don't implement IAdaptable or even IPropertySource.
The Tabbed Properties View, explained here:
http://www.eclipse.org/articles/Article-Tabbed-Properties/tabbed_properties_view.html
seems to be a simple possibility - but only for inputs that implement IAdaptable.
I've thought about implementing my own IPropertySheetPage but the only implementations I found are the built-in PropertySheetPage and TabbedPropertySheetPage which are very complex.
Is there another way to create a properties view for input elements that don't implement IAdaptable? Can I use Tabbed Properties View in a way I don't see yet? Are there any other less complex implementations of IPropertySheetPage, I can look at?
Thank you!
Kristina
Actually, you can write an IAdapterFactory for objects which don't implement IAdaptable and register it in plugin.xml or in your plugin activator. See http://www.eclipsezone.com/eclipse/forums/t61666.html.
Are there any other less complex implementations of IPropertySheetPage, I can look at?
Short answer: No.
But why don't you wrap the non-adaptable object into your own object that implements IAdaptable or IPropertySource or whatever, so that the property-page can work with your wrapper which holds the object you want to make editable through the property-page. And instead of providing this "library" object to global adapter-mechanism, create the wrapper, set the object and provide it to your global selection-service or whatever.
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.