[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [emf-dev] Allowing custom property editors
|
Hi all,
We have within a Papyrus a framework to model property view configuration and display related custum property view configuration. I cc Camille that may give you more information related that framework if you are interested.
Best... Sébastien.
------------------------------------------------------------------------------------------------------------------------------------------
Sébastien Gérard
Head of the LISE labs and leader of the Eclipse Papyrus project (www.eclipse.org/papyrus).
+33 (0)1 69 08 58 24 / +33(0)6 88 20 00 47
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
DILS/Laboratoire d'Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE),
Point Courrier n°174
91 191 Gif sur Yvette CEDEX
-----Message d'origine-----
De : emf-dev-bounces@xxxxxxxxxxx [mailto:emf-dev-bounces@xxxxxxxxxxx] De la part de Jens Reimann
Envoyé : mercredi 18 juin 2014 16:59
À : emf-dev@xxxxxxxxxxx
Objet : [emf-dev] Allowing custom property editors
Hi,
I just stumbled over the issue again that I would like to have a custom property editor for the EMF generated editors. However this seems to be a bigger task. Either one has to replace a lot of generated classes or use some other toolset like EEF.
I think there is way to do this with EMF.Edit and started performing the changes in our own project, Eclipse SCADA. However I would like to see the changes become part of EMF, if possible.
As far as I have figured it out, the basic problem is, that AdapterFactoryContentProvider creates the actual IPropertySource instance, which is derived from a IItemPropertyDescriptor. This process takes place in PropertyDescriptor.createPropertyEditor(...). However there seems to be no extensible way to intercept this process and inject a custom property editor.
I started with a small patch in gerrit [1] which basically allows other adapters to join in when the conversion from "Object" to "IPropertySource" takes place. This would be a first step to allow others to inject custom property editors, if needed. Otherwise the default process takes place.
This could also be done in a custom implementation on a per project
(editor) base. However if you have a bigger set or models and extension models. This would mean that all editors have to use this extended version of AdapterFactoryContentProvider. If one editor implementation still uses the default implementation, then the whole process would be broken for a extending model.
Please let me know what you think.
Jens Reimann
[1] https://git.eclipse.org/r/#/c/28689/
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
