Community
Participate
Working Groups
Build Identifier: 20100617-1415 EMF can now generate edit and editor code that runs on the Rich Ajax Platform. Unfortunately, code generated by EEF and the EEF runtime plugin are not compatible with RAP. In XXXPropertiesEditionPartForm, FormToolkit.paintBordersFor(Composite) is commented out in the RAP version of Eclipse Forms. The reason and workaround is pulled right from the FormToolkit source file: // RAP [rh] paintBordersFor not useful as no GC to actually paint borders ... // * ... If a control needs a border but is not on its list, it is // * possible to force border in the following way: // * widget.setData(FormToolkit.KEY_DRAW_BORDER, FormToolkit.TREE_BORDER); // * or // * widget.setData(FormToolkit.KEY_DRAW_BORDER, FormToolkit.TEXT_BORDER); The EEF runtime plugin has required dependencies on the RCP plugins org.eclipse.ui, org.eclipse.emf.edit.ui, and org.eclipse.jface.databinding plugins. Adding the RAPified versions of these plugins (org.eclipse.rap.ui, org.eclipse.emf.rap.edit.ui, org.eclipse.rap.jface.databinding) and changing the RCP plugins to be optional requires the following additional RAP plugins org.eclipse.rap.ui.forms and org.eclipse.rap.ui.views. This leads to more problems because the EEF runtime uses the following APIs that are not supported by RAP: EEFImageViewer uses FileDialog, which will probably never be RAPified PatternTool depends on JDT's SearchPattern class and the core JDT is not compatible with RAP ModelChooserDialog uses WorkbenchContentProvider, a class that has no RAP equivalent PropertiesEditionViewer's constructor is calling CTabFolder.setSimple(false), a method that has not been RAPified Reproducible: Always
Hi matt, thanks for your attempt to use EEF in a RAP application. we will have a look to your issues, but porting EEF on RAP is not in our plan yet. You can still attach here some patch for a RAPified version of EEF if you did some.
The Eclipse EEF team has worked over the past few months on a brand new runtime using a reflective approach which can be used more easily with Eclipse Sirius. Since we do not plan to continue to work on the old runtime and its code generation approach, I will close this issue for now. If you want to contribute, you can reopen this issue and submit a contribution to the project thanks to our Gerrit: https://git.eclipse.org/r/#/admin/projects/eef/org.eclipse.eef
