Community
Participate
Working Groups
Build Identifier: Add additions Nodeditpart.xpt for installing custom editpolicies Reproducible: Always
Created attachment 205282 [details] Patch This extension should do the job.
I think this use-case is intended to be resolved by the org.eclipse.gmf.runtime.diagram.ui.editpolicyProviders extension point. Did you try using it?
Hello, editpolicyProviders will not work, I tried it once, don't yet know whether it is intentional or not. However, the intended way to add the editploicies via templates is to register them in GenModel as CustomBehavior's. Why don't this work for you? Regards, Michael
FYI editPolicyProvider *DO WORK*. They are extensively used in Bonita for instance. Moreover the pattern of contributing extension is IMHO much easier and "agile" than changing the model.
Hi, how can one specify the role to use the editpolicy for? I would like to remove the popupbar role and place my own instead. However it seems that one cannot specify the role through this extension point. I did the following: <extension point="xxx.editpolicyProviders"> <editpolicyProvider class="xxx.XXXPopupBarEditPolicy"> <Priority name="Lowest"> </Priority> <context editparts="XXX_3060, XXX_3069, XXX_3072"></context> </editpolicyProvider> </extension> I also see the problem that the IDs are not stable. They somehow sometimes change overtime. I think the cleanest way would be to define the editpolicies in the genmodel? One could then automate this via a custom transformation during the genmodel creation process. What do you think about such an option? Ralph
Ralph, have you seen this? http://wiki.eclipse.org/GMF_Newsgroup_Q_and_A#How_do_I_install_an_EditPolicyProvider.3F
Re: I think the cleanest way would be to define the editpolicies in the genmodel? One could then automate this via a custom transformation during the genmodel creation process. What do you think about such an option? Yes, its exactly how I see it, and this is one of the reasons we are going to open the map2gen transformation and allow to plug into it. This is (plugging into the bridge, not the installing editpolicies through this:) ) is one of the main goals for 3.0 release. Regards, Michael
We should reconsider this for 3.0M5. I still don't like the idea of registering edit-policies from templates in favor to using CustomBehavior's. With new QVTO bridge and user defined post-bridge transformation it should be easy to define the transformation that creates a couple of custom behaviors for choosen editparts and adds them as a custom-behaviors for GenCommnBase's. At the other side, the DEFINE additions itself will not hurt anyone.
