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.
Related
I would like to know. How I can dynamically choose view? I would like to make the PropertyGrid in my application. The PropertyGrid should must change when user selects object. As I understand for this task I have to use a DataTemplate but how I can dynamically create DataTemplate in code? The fact is that I use plug-ins and View and ViewModel for each plugin located in separate dll and so I can't directly write DataTemplate in PropertyesViewModel.
How can I make the edit properties for each plugin using the Propertygrid if I can't use a DataTemplate?
For Catel it doesn't matter in which assemblies the views / view models are located since it uses relative naming conventions. However, if you want to show a custom view based on logic that might reside inside a plugin, I think this is out of scope for Catel.
To solve this issue, you must implement a custom service that can communicate with the plugins and resolve the right view for a selected object. One solution might be naming conventions (if it's a PersonModel, you might want to show the PersonPropertiesView and PersonPropertiesViewModel). However, this must be a custom service.
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
so I'm having a lot of classes that use the UIBinder to make the layout. Each one of those classes has a lot of added features in it though, so it's starting to get a little bit cluttered. My idea was to make a GUI class, where I will initialize the UiFields, and to make a class extend that one, and handle all the events in the subclass.
My problem is, the ClickHandlers are not working anymore. Anyone knows why?
Also is it bad practice to do it this way?
You probably have to implement HasHandlers interface and make sure you GUI extends composite
In my application I've got about a dozen places where I need to show a country suggest box. All the code of the suggest box(including the creation of a custom SuggestOracle, it's initialization and various handlers) take up some ~100 lines of and copying it all over the project seems quite hardcore for me.
So I decided to write a custom CountrySuggestBox which extended SuggestBox wrapped in itself the construction of my custom SuggestOracle and did all the click/key handling stuff in itself. After this I was planning to just write something in the lines of #UiFiled(provided=true) CountrySuggestBox = new CountrySuggestBox(countryList); and be done with it. But for that I also need CountrySuggestBox to implement LeafValueEditor<Country> which i can't do cause SuggestBox implements HasText and these interfaces do not "like" each other.
So how can I make CountrySuggestBox an editor of country types property without writing custom editor methods in the classes using it.
Prefer composition over inheritance.
Have CountrySuggestBox extend Composite (or simply implement IsWidget) and wrap the SuggestBox.
Then you can make it a LeafValueEditor<Country> or IsEditor<LeafValueEditor<Country>> (along with TakesValue<Country> or HasValue<Country>)
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.