Home » Modeling » EMF » [EMF] Adapter Factory
[EMF] Adapter Factory [message #423556] |
Thu, 02 October 2008 08:25 |
Tristan Faure Messages: 460 Registered: July 2009 |
Senior Member |
|
|
Hi !
today i have a question about emf.edit
If I have a metamodel : org.eclipse.mymetamodel
I know that all generated editors will have a reference to
org.eclipse.mymetamodel.edit.provider.MymetamodelItemProvide rAdapterFactory
(with standard options) to have label and image information
In my case I want to design a
CustomMymetamodelItemProviderAdapterFactory (maybe by generation) which
will provides more information in label for example only if an option is
activated
and I don't know how to that
1. If I know what kind of editor is used i thought to change the edit
factory attribute by introspection but i want a generic mechanism
without knowing the target editor and it's not very clean :/
2. I can modify the edit generation template and adding a genmodel
action to generate a org.eclipse.mymetamodel.edit with my own options
but it means to rebuild the plugin and it's not the bast case
Do you know a way to "adapt" by extension the edit factory for an eobject
to summarize :
1 - A user has an environment with
- a metamodel plugin
- an edit plugin
- an editor plugin or a gmf editor
2- The user add a custom edit plugin (maybe generated) and this plugin
will replace the original edit plugin at the runtime if the user select
the option
Do you see a way for me to resolve this problem ?
|
|
| | |
Re: [EMF] Adapter Factory [message #423563 is a reply to message #423562] |
Thu, 02 October 2008 12:14 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Hi,
In my EMF-Example project I have an completely configureable
LabelProvider (it currently uses commons.lang and implements some
special databinding semantics but could get easily retrofitted to
MessageFormat and Plain EMF) [1].
It allows:
- formatt patterns
- access to nested attributes (e.g. address.country.name)
- conditional formatting (e.g. switch template for object-types, value
is null)
Tom
[1] http://publicsvn.bestsolution.at/repos/java/examples/EMF-Dat abinding/at.bestsolution.soccer.ui.common/src/at/bestsolutio n/soccer/ui/common/viewers/ObservableColumnLabelProvider.jav a
Víctor Roldán Betancort schrieb:
> Hi Trisan,
>
> while working with CDO I experienced something similar.
>
> CDO has for its generic editor a custom extension of
> AdapterFactoryLabelProvider called CDOLabelProvider. Furthermore, Eike
> added to it mechanism to customize how the label would look like by the
> means of a pattern. I suggested adding a constructor passing a pattern,
> this way, any caller can decide how the label would look like. An editor
> could then specify a pattern, telling the object how it wants things to
> be shown. It would solve your problem at point #1.
>
> Eike told me Ed is willing to add this functionality in EMF. If you
> want, we could collaborate on making a patch for this. I believe this
> could be very beneficial for the community. Any other interest parties
> are welcome as well.
>
>> 2- The user add a custom edit plugin (maybe generated) and this plugin
>> will replace the original edit plugin at the runtime if the user
>> select the option
>
> With this proposal there is no need of generating new edit plugins.
>
> We could make it in such a way that an editor specifies the pattern in a
> configuration file... So you have one editor, and multiple visualization
> configurations... just ideas.
>
> What do you think?
>
> Ed, could you give us you opinion about my proposal?
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
Re: [EMF] Adapter Factory [message #423566 is a reply to message #423562] |
Thu, 02 October 2008 12:28 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
Víctor,
Comments beow.
Víctor Roldán Betancort wrote:
> Hi Trisan,
>
> while working with CDO I experienced something similar.
>
> CDO has for its generic editor a custom extension of
> AdapterFactoryLabelProvider called CDOLabelProvider. Furthermore, Eike
> added to it mechanism to customize how the label would look like by
> the means of a pattern. I suggested adding a constructor passing a
> pattern, this way, any caller can decide how the label would look
> like. An editor could then specify a pattern, telling the object how
> it wants things to be shown. It would solve your problem at point #1.
>
> Eike told me Ed is willing to add this functionality in EMF. If you
> want, we could collaborate on making a patch for this. I believe this
> could be very beneficial for the community. Any other interest parties
> are welcome as well.
It's slipped my mind. Is the idea to avoid having to hand modify the
getText method?
>
>> 2- The user add a custom edit plugin (maybe generated) and this
>> plugin will replace the original edit plugin at the runtime if the
>> user select the option
>
> With this proposal there is no need of generating new edit plugins.
>
> We could make it in such a way that an editor specifies the pattern in
> a configuration file... So you have one editor, and multiple
> visualization configurations... just ideas.
>
> What do you think?
>
> Ed, could you give us you opinion about my proposal?
It's not clear to me yet what the idea is. Passing arguments into the
constructor of the factory and then passing them to each item provider
sounds like a pretty significant design change. Another issue that's
come up is that it's often the case that in some contexts you'd need a
fully qualified name and in others a simple name, because the context
provides the qualification. I'm not sure how best to generalize all
these differing needs... An argument passed to the getText method
itself would be another way...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: [EMF] Adapter Factory [message #423569 is a reply to message #423566] |
Thu, 02 October 2008 12:42 |
Tristan Faure Messages: 460 Registered: July 2009 |
Senior Member |
|
|
Hi Victor Thank you for your participation ;) !
Ed Merks a écrit :
> Víctor,
>
> Comments beow.
>
> Víctor Roldán Betancort wrote:
>> Hi Trisan,
>>
>> while working with CDO I experienced something similar.
>>
>> CDO has for its generic editor a custom extension of
>> AdapterFactoryLabelProvider called CDOLabelProvider. Furthermore, Eike
>> added to it mechanism to customize how the label would look like by
>> the means of a pattern. I suggested adding a constructor passing a
>> pattern, this way, any caller can decide how the label would look
>> like. An editor could then specify a pattern, telling the object how
>> it wants things to be shown. It would solve your problem at point #1.
>>
>> Eike told me Ed is willing to add this functionality in EMF. If you
>> want, we could collaborate on making a patch for this. I believe this
>> could be very beneficial for the community. Any other interest parties
>> are welcome as well.
> It's slipped my mind. Is the idea to avoid having to hand modify the
> getText method?
>>
>>> 2- The user add a custom edit plugin (maybe generated) and this
>>> plugin will replace the original edit plugin at the runtime if the
>>> user select the option
>>
>> With this proposal there is no need of generating new edit plugins.
>>
>> We could make it in such a way that an editor specifies the pattern in
>> a configuration file... So you have one editor, and multiple
>> visualization configurations... just ideas.
>>
>> What do you think?
>>
>> Ed, could you give us you opinion about my proposal?
> It's not clear to me yet what the idea is. Passing arguments into the
> constructor of the factory and then passing them to each item provider
> sounds like a pretty significant design change. Another issue that's
> come up is that it's often the case that in some contexts you'd need a
> fully qualified name and in others a simple name, because the context
> provides the qualification. I'm not sure how best to generalize all
> these differing needs... An argument passed to the getText method
> itself would be another way...
The other problem is if the getText method depends on environment for
example in my case i want to append text to the getText Method and
passing arguments is not sufficient for me. A solution could be for
editor makers to provide LabelProvider Extensions like CDOLabelProvider
but permitting to override the getText or modifying it's value
|
|
|
Re: [EMF] Adapter Factory [message #423570 is a reply to message #423569] |
Thu, 02 October 2008 12:45 |
Tristan Faure Messages: 460 Registered: July 2009 |
Senior Member |
|
|
Sorry for a double post
but can we imagine a chain mechanism for label provider ?
As a listener we add a chain and when the label made it's operation he
can call the next chain to complete the label or anything else ?
Tristan FAURE a écrit :
> Hi Victor Thank you for your participation ;) !
>
> Ed Merks a écrit :
>> Víctor,
>>
>> Comments beow.
>>
>> Víctor Roldán Betancort wrote:
>>> Hi Trisan,
>>>
>>> while working with CDO I experienced something similar.
>>>
>>> CDO has for its generic editor a custom extension of
>>> AdapterFactoryLabelProvider called CDOLabelProvider. Furthermore,
>>> Eike added to it mechanism to customize how the label would look like
>>> by the means of a pattern. I suggested adding a constructor passing a
>>> pattern, this way, any caller can decide how the label would look
>>> like. An editor could then specify a pattern, telling the object how
>>> it wants things to be shown. It would solve your problem at point #1.
>>>
>>> Eike told me Ed is willing to add this functionality in EMF. If you
>>> want, we could collaborate on making a patch for this. I believe this
>>> could be very beneficial for the community. Any other interest
>>> parties are welcome as well.
>> It's slipped my mind. Is the idea to avoid having to hand modify the
>> getText method?
>>>
>>>> 2- The user add a custom edit plugin (maybe generated) and this
>>>> plugin will replace the original edit plugin at the runtime if the
>>>> user select the option
>>>
>>> With this proposal there is no need of generating new edit plugins.
>>>
>>> We could make it in such a way that an editor specifies the pattern
>>> in a configuration file... So you have one editor, and multiple
>>> visualization configurations... just ideas.
>>>
>>> What do you think?
>>>
>>> Ed, could you give us you opinion about my proposal?
>> It's not clear to me yet what the idea is. Passing arguments into the
>> constructor of the factory and then passing them to each item provider
>> sounds like a pretty significant design change. Another issue that's
>> come up is that it's often the case that in some contexts you'd need a
>> fully qualified name and in others a simple name, because the context
>> provides the qualification. I'm not sure how best to generalize all
>> these differing needs... An argument passed to the getText method
>> itself would be another way...
>
> The other problem is if the getText method depends on environment for
> example in my case i want to append text to the getText Method and
> passing arguments is not sufficient for me. A solution could be for
> editor makers to provide LabelProvider Extensions like CDOLabelProvider
> but permitting to override the getText or modifying it's value
|
|
| |
Re: [EMF] Adapter Factory [message #423572 is a reply to message #423566] |
Thu, 02 October 2008 12:50 |
Victor Roldan Betancort Messages: 524 Registered: July 2009 |
Senior Member |
|
|
Ed Merks escribió:
> Víctor,
>
> Comments beow.
>
> Víctor Roldán Betancort wrote:
>> Hi Trisan,
>>
>> while working with CDO I experienced something similar.
>>
>> CDO has for its generic editor a custom extension of
>> AdapterFactoryLabelProvider called CDOLabelProvider. Furthermore, Eike
>> added to it mechanism to customize how the label would look like by
>> the means of a pattern. I suggested adding a constructor passing a
>> pattern, this way, any caller can decide how the label would look
>> like. An editor could then specify a pattern, telling the object how
>> it wants things to be shown. It would solve your problem at point #1.
>>
>> Eike told me Ed is willing to add this functionality in EMF. If you
>> want, we could collaborate on making a patch for this. I believe this
>> could be very beneficial for the community. Any other interest parties
>> are welcome as well.
> It's slipped my mind. Is the idea to avoid having to hand modify the
> getText method?
Sorry Ed, hope this helps you recall:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247281
I'm not sure, but I believe we wouldn't need to modify getText anymore.
Eike's CDOLabelProvider.getText() looks like this.
public String getText(Object object)
{
return decorateText(super.getText(object), object);
}
decorateText modifies the text to be shown according to the pattern
provided.
>>
>>> 2- The user add a custom edit plugin (maybe generated) and this
>>> plugin will replace the original edit plugin at the runtime if the
>>> user select the option
>>
>> With this proposal there is no need of generating new edit plugins.
>>
>> We could make it in such a way that an editor specifies the pattern in
>> a configuration file... So you have one editor, and multiple
>> visualization configurations... just ideas.
>>
>> What do you think?
>>
>> Ed, could you give us you opinion about my proposal?
> It's not clear to me yet what the idea is. Passing arguments into the
> constructor of the factory and then passing them to each item provider
> sounds like a pretty significant design change.
We aren't modifying the current constructor, but rather adding a new one
with a "DecoratorPattern". The LabelProvider internally modifies the
returned text according to the pattern.
Anyway, I think Eike could clarify what I tried to transmit here.
|
|
|
Re: [EMF] Adapter Factory [message #423574 is a reply to message #423569] |
Thu, 02 October 2008 12:53 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
Tristan,
Comments below.
Tristan FAURE wrote:
> Hi Victor Thank you for your participation ;) !
>
> Ed Merks a écrit :
>> Víctor,
>>
>> Comments beow.
>>
>> Víctor Roldán Betancort wrote:
>>> Hi Trisan,
>>>
>>> while working with CDO I experienced something similar.
>>>
>>> CDO has for its generic editor a custom extension of
>>> AdapterFactoryLabelProvider called CDOLabelProvider. Furthermore,
>>> Eike added to it mechanism to customize how the label would look
>>> like by the means of a pattern. I suggested adding a constructor
>>> passing a pattern, this way, any caller can decide how the label
>>> would look like. An editor could then specify a pattern, telling the
>>> object how it wants things to be shown. It would solve your problem
>>> at point #1.
>>>
>>> Eike told me Ed is willing to add this functionality in EMF. If you
>>> want, we could collaborate on making a patch for this. I believe
>>> this could be very beneficial for the community. Any other interest
>>> parties are welcome as well.
>> It's slipped my mind. Is the idea to avoid having to hand modify the
>> getText method?
>>>
>>>> 2- The user add a custom edit plugin (maybe generated) and this
>>>> plugin will replace the original edit plugin at the runtime if the
>>>> user select the option
>>>
>>> With this proposal there is no need of generating new edit plugins.
>>>
>>> We could make it in such a way that an editor specifies the pattern
>>> in a configuration file... So you have one editor, and multiple
>>> visualization configurations... just ideas.
>>>
>>> What do you think?
>>>
>>> Ed, could you give us you opinion about my proposal?
>> It's not clear to me yet what the idea is. Passing arguments into
>> the constructor of the factory and then passing them to each item
>> provider sounds like a pretty significant design change. Another
>> issue that's come up is that it's often the case that in some
>> contexts you'd need a fully qualified name and in others a simple
>> name, because the context provides the qualification. I'm not sure
>> how best to generalize all these differing needs... An argument
>> passed to the getText method itself would be another way...
>
> The other problem is if the getText method depends on environment for
> example in my case i want to append text to the getText Method and
> passing arguments is not sufficient for me.
It sounded like passing in arguments was the solution being proposed...
> A solution could be for editor makers to provide LabelProvider
> Extensions like CDOLabelProvider but permitting to override the
> getText or modifying it's value
Yes, the idea of decorators. Decorators might apply for icons as well...
You might, for example, declare a factory that supports some "decorator"
API and register it like this:
<extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
<factory
uri="http://www.example.com/Library"
class=" com.example.library.provider.LibraryItemDecoratorProviderAda pterFactory "
supportedTypes="com.example.IItemDecoratorProvider"/>
</extension>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: [EMF] Adapter Factory [message #423575 is a reply to message #423570] |
Thu, 02 October 2008 12:54 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
Tristan,
Yes, "decorators" would make sense.
Tristan FAURE wrote:
> Sorry for a double post
>
> but can we imagine a chain mechanism for label provider ?
>
> As a listener we add a chain and when the label made it's operation he
> can call the next chain to complete the label or anything else ?
>
>
> Tristan FAURE a écrit :
>> Hi Victor Thank you for your participation ;) !
>>
>> Ed Merks a écrit :
>>> Víctor,
>>>
>>> Comments beow.
>>>
>>> Víctor Roldán Betancort wrote:
>>>> Hi Trisan,
>>>>
>>>> while working with CDO I experienced something similar.
>>>>
>>>> CDO has for its generic editor a custom extension of
>>>> AdapterFactoryLabelProvider called CDOLabelProvider. Furthermore,
>>>> Eike added to it mechanism to customize how the label would look
>>>> like by the means of a pattern. I suggested adding a constructor
>>>> passing a pattern, this way, any caller can decide how the label
>>>> would look like. An editor could then specify a pattern, telling
>>>> the object how it wants things to be shown. It would solve your
>>>> problem at point #1.
>>>>
>>>> Eike told me Ed is willing to add this functionality in EMF. If you
>>>> want, we could collaborate on making a patch for this. I believe
>>>> this could be very beneficial for the community. Any other interest
>>>> parties are welcome as well.
>>> It's slipped my mind. Is the idea to avoid having to hand modify
>>> the getText method?
>>>>
>>>>> 2- The user add a custom edit plugin (maybe generated) and this
>>>>> plugin will replace the original edit plugin at the runtime if the
>>>>> user select the option
>>>>
>>>> With this proposal there is no need of generating new edit plugins.
>>>>
>>>> We could make it in such a way that an editor specifies the pattern
>>>> in a configuration file... So you have one editor, and multiple
>>>> visualization configurations... just ideas.
>>>>
>>>> What do you think?
>>>>
>>>> Ed, could you give us you opinion about my proposal?
>>> It's not clear to me yet what the idea is. Passing arguments into
>>> the constructor of the factory and then passing them to each item
>>> provider sounds like a pretty significant design change. Another
>>> issue that's come up is that it's often the case that in some
>>> contexts you'd need a fully qualified name and in others a simple
>>> name, because the context provides the qualification. I'm not sure
>>> how best to generalize all these differing needs... An argument
>>> passed to the getText method itself would be another way...
>>
>> The other problem is if the getText method depends on environment for
>> example in my case i want to append text to the getText Method and
>> passing arguments is not sufficient for me. A solution could be for
>> editor makers to provide LabelProvider Extensions like
>> CDOLabelProvider but permitting to override the getText or modifying
>> it's value
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: [EMF] Adapter Factory [message #423576 is a reply to message #423571] |
Thu, 02 October 2008 12:58 |
Tristan Faure Messages: 460 Registered: July 2009 |
Senior Member |
|
|
Ed,
comments bellow
Ed Merks a écrit :
> Tristan,
>
> Comments beow.
>
>
> Tristan FAURE wrote:
>> Ed
>>
>> Ed Merks a écrit :
>>> Tristan,
>>>
>>> Comments below.
>>>
>>>
>>> Tristan FAURE wrote:
>>>> Hi !
>>>> today i have a question about emf.edit
>>> Maybe I should answer your questions more slowly. :-P
>>
>> And I thank you !
>>
>>>>
>>>> If I have a metamodel : org.eclipse.mymetamodel
>>>>
>>>> I know that all generated editors will have a reference to
>>>> org.eclipse.mymetamodel.edit.provider.MymetamodelItemProvide rAdapterFactory
>>>> (with standard options) to have label and image information
>>> Yes, though technically that's redundant. An adapter factory created
>>> like this would find it anyway:
>>>
>>> adapterFactory = new
>>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>>>
>>>
>>>>
>>>>
>>>> In my case I want to design a
>>>> CustomMymetamodelItemProviderAdapterFactory (maybe by generation)
>>>> which will provides more information in label for example only if an
>>>> option is activated
>>>>
>>>> and I don't know how to that
>>>>
>>>> 1. If I know what kind of editor is used i thought to change the
>>>> edit factory attribute by introspection but i want a generic
>>>> mechanism without knowing the target editor and it's not very clean :/
>>> I'm not sure where you're wanting to put the decision logic. I
>>> imagine that typically the code building the view would want to
>>> decide which option to supply...
>>>>
>>>> 2. I can modify the edit generation template and adding a genmodel
>>>> action to generate a org.eclipse.mymetamodel.edit with my own options
>>>> but it means to rebuild the plugin and it's not the bast case
>>> XSDSemanticItemProviderAdapterFactory is an example of a factory
>>> specialized from XSDItemProviderAdapterFactory. It doesn't use
>>> options but I suppose I could have has one factory that took an
>>> option argument and behaved own of two different ways...
>>
>> Sorry I don't understand this point about these factories ... :/
> Did you have a look at them? If you open a schema with the sample XML
> Schema editor, you'll see how it induces as different view for the
> Semantics tab than in the Overview...
Yes thank you for your precision I've just seen that
>>
>>>>
>>>> Do you know a way to "adapt" by extension the edit factory for an
>>>> eobject
>>> It seems to me you ought to pick a default that clients get by
>>> default and that anything beyond that is picked up at the digression
>>> of the client.
>>>>
>>>> to summarize :
>>>> 1 - A user has an environment with
>>>> - a metamodel plugin
>>>> - an edit plugin
>>>> - an editor plugin or a gmf editor
>>>> 2- The user add a custom edit plugin (maybe generated) and this
>>>> plugin will replace the original edit plugin at the runtime if the
>>>> user select the option
>>> And what if they add two such replacements? The existing mechanisms
>>> allow one to register a factory that will be used. But there can
>>> only be one such registered factory. Perhaps the earlier point about
>>> the hard code registration being redundant is the key point here. If
>>> that hard coded factory were absent, that would help. but the .edit
>>> plugin registers it's version and isn't expecting anyone to override
>>> that (and couldn't tolerate more than one such replacement in any case).
>>
>> I've seen the edit factory registration by .edit plugin but default
>> editors (EMF & GMF) doesn't really use this information during the
>> generation
> The point about registration is they're used at runtime. As I
> mentioned, the explicit use of the generated factory in the generated
> editor is actually redundant.
>>
>>>>
>>>> Do you see a way for me to resolve this problem ?
>>> The editor itself could define an extension point...
>>
>> I think defining an extension point in editor could be a good point
>> but we are never sure that this extension point is filled
> When it's not, the default EMF.Edit registered one could be used...
>>
>> I'm a little bit surprised that there is no mechanisms to override a
>> content providerEd Merks a écrit :
> Tristan,
>
> Comments beow.
>
>
> Tristan FAURE wrote:
>> Ed
>>
>> Ed Merks a écrit :
>>> Tristan,
>>>
>>> Comments below.
>>>
>>>
>>> Tristan FAURE wrote:
>>>> Hi !
>>>> today i have a question about emf.edit
>>> Maybe I should answer your questions more slowly. :-P
>>
>> And I thank you !
>>
>>>>
>>>> If I have a metamodel : org.eclipse.mymetamodel
>>>>
>>>> I know that all generated editors will have a reference to
>>>> org.eclipse.mymetamodel.edit.provider.MymetamodelItemProvide rAdapterFactory
>>>> (with standard options) to have label and image information
>>> Yes, though technically that's redundant. An adapter factory created
>>> like this would find it anyway:
>>>
>>> adapterFactory = new
>>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>>>
>>>
>>>>
>>>>
>>>> In my case I want to design a
>>>> CustomMymetamodelItemProviderAdapterFactory (maybe by generation)
>>>> which will provides more information in label for example only if an
>>>> option is activated
>>>>
>>>> and I don't know how to that
>>>>
>>>> 1. If I know what kind of editor is used i thought to change the
>>>> edit factory attribute by introspection but i want a generic
>>>> mechanism without knowing the target editor and it's not very clean :/
>>> I'm not sure where you're wanting to put the decision logic. I
>>> imagine that typically the code building the view would want to
>>> decide which option to supply...
>>>>
>>>> 2. I can modify the edit generation template and adding a genmodel
>>>> action to generate a org.eclipse.mymetamodel.edit with my own options
>>>> but it means to rebuild the plugin and it's not the bast case
>>> XSDSemanticItemProviderAdapterFactory is an example of a factory
>>> specialized from XSDItemProviderAdapterFactory. It doesn't use
>>> options but I suppose I could have has one factory that took an
>>> option argument and behaved own of two different ways...
>>
>> Sorry I don't understand this point about these factories ... :/
> Did you have a look at them? If you open a schema with the sample XML
> Schema editor, you'll see how it induces as different view for the
> Semantics tab than in the Overview...
>>
>>>>
>>>> Do you know a way to "adapt" by extension the edit factory for an
>>>> eobject
>>> It seems to me you ought to pick a default that clients get by
>>> default and that anything beyond that is picked up at the digression
>>> of the client.
>>>>
>>>> to summarize :
>>>> 1 - A user has an environment with
>>>> - a metamodel plugin
>>>> - an edit plugin
>>>> - an editor plugin or a gmf editor
>>>> 2- The user add a custom edit plugin (maybe generated) and this
>>>> plugin will replace the original edit plugin at the runtime if the
>>>> user select the option
>>> And what if they add two such replacements? The existing mechanisms
>>> allow one to register a factory that will be used. But there can
>>> only be one such registered factory. Perhaps the earlier point about
>>> the hard code registration being redundant is the key point here. If
>>> that hard coded factory were absent, that would help. but the .edit
>>> plugin registers it's version and isn't expecting anyone to override
>>> that (and couldn't tolerate more than one such replacement in any case).
>>
>> I've seen the edit factory registration by .edit plugin but default
>> editors (EMF & GMF) doesn't really use this information during the
>> generation
> The point about registration is they're used at runtime. As I
> mentioned, the explicit use of the generated factory in the generated
> editor is actually redundant.
>>
>>>>
>>>> Do you see a way for me to resolve this problem ?
>>> The editor itself could define an extension point...
>>
>> I think defining an extension point in editor could be a good point
>> but we are never sure that this extension point is filled
> When it's not, the default EMF.Edit registered one could be used...
>>
>> I'm a little bit surprised that there is no mechanisms to override a
>> content provider
> How many extension points support not only one extension, but also
> overriding that existing extension with yet another extension? Keep in
> mind that Eclipse is designed to be able to compose contributions from
> many sources so an editor that says "you can replace my viewing
> mechanisms with another one" is setting itself up for conflicts with two
> different Tristans both decide they want to change how things look...
>>
>> My problem (if you remember) is to define rights management for users
>> and if this option is enabled i want to append to a label element the
>> user's rights (Read/Write/Delete) With maybe a generic plugin with
>> some customizations via extension points or preference page or with a
>> generated plugin
> This effectively is requiring all item providers to allow themselves to
> be replaced. Eclipse has a notion of decorators that I've never
> explored which likely is a better fit for this type of mechanism...
>>
>> Forking to this discussion I've tried to design a GenericAdapter and a
>> GenericAdapterFactory which delegates behavior to a corresponding
>> factory but I see that I've some problems with editing domains and
>> display in GMF. Maybe i'm looking to the wrong side and an other
>> solution would be easier ?
> It's not clear to me yet why you can't do what's needed in the generated
> item providers for your model. Are you trying to inject this into
> someone else's editor?
>>
>>
> How many extension points support not only one extension, but also
> overriding that existing extension with yet another extension? Keep in
> mind that Eclipse is designed to be able to compose contributions from
> many sources so an editor that says "you can replace my viewing
> mechanisms with another one" is setting itself up for conflicts with two
> different Tristans both decide they want to change how things look...
Ok I understand the possible conflicts
>>
>> My problem (if you remember) is to define rights management for users
>> and if this option is enabled i want to append to a label element the
>> user's rights (Read/Write/Delete) With maybe a generic plugin with
>> some customizations via extension points or preference page or with a
>> generated plugin
> This effectively is requiring all item providers to allow themselves to
> be replaced. Eclipse has a notion of decorators that I've never
> explored which likely is a better fit for this type of mechanism...
I can see that thank you for the info (and i currently see that you are
talking about in next subject thank's ! :p)
>>
>> Forking to this discussion I've tried to design a GenericAdapter and a
>> GenericAdapterFactory which delegates behavior to a corresponding
>> factory but I see that I've some problems with editing domains and
>> display in GMF. Maybe i'm looking to the wrong side and an other
>> solution would be easier ?
> It's not clear to me yet why you can't do what's needed in the generated
> item providers for your model. Are you trying to inject this into
> someone else's editor?
It's exactly what i mean, i need to inject my labels in editor already built
>>
>>
|
|
|
Goto Forum:
Current Time: Fri Mar 29 10:17:13 GMT 2024
Powered by FUDForum. Page generated in 0.06277 seconds
|