Community
Participate
Working Groups
Currently it's really difficult to provide a custom cell editor for a property/feature. One has to subclass AdapterFactoryContentProvider, PropertySource and PropertyDescriptor and add that manually to every editor which uses the model (directly or referenced). One way to solve the problem would be to add a createCellEditor to IItemDescriptor and make PropertyDescritptor delegate to it. However, since the edit-code shouln't be dependent on org.eclipse.ui.views and swt (createCellEditor takes Composite as parameter and returns CellEditor) the method would need to use Object as input and return values. This would make things very easy but is still quite "hacky". Another apporach would be to simply add 2 callbacks in IItemPropertyDescriptor: boolean hasExtendedCellEditor(Object object) and void runExtendedCellEditor(Object object) So if the first method returns true, the "..." button is rendered in the cell and runExtendedCellEditor() is invoked if the user clicks on it. This method can then open a dialog (which most of the custom editors will do anyway). This would at least have worked for me (We needed a FileSelection dialog which stores the result in a string property and a special Date+Time selector). best regards Andreas
I'm not really happy with either approach. Perhaps a better approach would be to add a method like /** * Returns an object that describes the type of editor to be used. */ public Object getEditorType(Object object); And then have some type of registry where you can register an instance of some API that will be called to create the cell editor for this type of property. If this returns null, we'd do what we always do. But if it doesn't, we'd have some something similar to the imagine (font, or color) registry to fetch a corresponding object that in turn will be used to create a cell editor. We might even have a GenFeature property for specifying this editor type value. This approach seems more extensible and in keeping with separating the item providers from the specifics of a particular rendering mechanism like JFace.
I agree with Ed's approach. It's definitely cleaner.
Hello, I've been working on adding extensibility for PropertyDescriptor in JWT project (such as replace TextArea by Combo Box for a cell editor...). I wrote a piece of code that returns a custom IPropertyDescriptor for a specified feature when an extension is present. My job was simplified by the fact that JWT already contains a "CustomAdapterFactoryContentProvider", that is an entry to get a content provider for any of our EMF objects. You can get more details looking at bug 240499. There are probably a lot of imperfections in that code, but it may contain some interesting things to implement such a feature in EMF. Regards, Mickael Istria
In https://bugs.eclipse.org/bugs/show_bug.cgi?id=438123 I've implemented a fully general solution for reusable customized cell editors. *** This bug has been marked as a duplicate of bug 438123 ***
