Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [emf-dev] Allowing custom property editors

Hi.

Well actually the idea was to do it in plain EMF.Edit. I know there are frameworks like EEF, Papyrus, etc.

However I want a simple and framework independent way.

But thanks for mentioning the idea! And please send me a pointer to more information. As I did not look deeper into Papyrus.

Best regards

Jens

On Jun 19, 2014 9:40 AM, GERARD Sebastien 166342 <Sebastien.GERARD@xxxxxx> wrote:
>
> 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 
> _______________________________________________ 
> emf-dev mailing list 
> emf-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/emf-dev 

Back to the top