Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [EMF] Adapter Factory
[EMF] Adapter Factory [message #423556] Thu, 02 October 2008 08:25 Go to next message
Tristan Faure is currently offline Tristan FaureFriend
Messages: 443
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 #423561 is a reply to message #423556] Thu, 02 October 2008 12:04 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30806
Registered: July 2009
Senior Member
Tristan,

Comments below.


Tristan FAURE wrote:
> Hi !
> today i have a question about emf.edit
Maybe I should answer your questions more slowly. :-P
>
> 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...
>
> 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).
>
> Do you see a way for me to resolve this problem ?
The editor itself could define an extension point...
Re: [EMF] Adapter Factory [message #423562 is a reply to message #423556] Thu, 02 October 2008 12:07 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
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?
Re: [EMF] Adapter Factory [message #423563 is a reply to message #423562] Thu, 02 October 2008 12:14 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6516
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30806
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...
Re: [EMF] Adapter Factory [message #423568 is a reply to message #423561] Thu, 02 October 2008 12:37 Go to previous messageGo to next message
Tristan Faure is currently offline Tristan FaureFriend
Messages: 443
Registered: July 2009
Senior Member
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 ... :/

>>
>> 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

>>
>> 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

I'm a little bit surprised that there is no mechanisms to override a
content provider

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

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 ?




Re: [EMF] Adapter Factory [message #423569 is a reply to message #423566] Thu, 02 October 2008 12:42 Go to previous messageGo to next message
Tristan Faure is currently offline Tristan FaureFriend
Messages: 443
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 Go to previous messageGo to next message
Tristan Faure is currently offline Tristan FaureFriend
Messages: 443
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 #423571 is a reply to message #423568] Thu, 02 October 2008 12:47 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30806
Registered: July 2009
Senior Member
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?
>
>
Re: [EMF] Adapter Factory [message #423572 is a reply to message #423566] Thu, 02 October 2008 12:50 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30806
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>
Re: [EMF] Adapter Factory [message #423575 is a reply to message #423570] Thu, 02 October 2008 12:54 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30806
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
Re: [EMF] Adapter Factory [message #423576 is a reply to message #423571] Thu, 02 October 2008 12:58 Go to previous message
Tristan Faure is currently offline Tristan FaureFriend
Messages: 443
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

>>
>>




Previous Topic:How to change a java model
Next Topic:ResourceImpl unload throws out of memory
Goto Forum:
  


Current Time: Mon Jan 20 18:46:24 GMT 2020

Powered by FUDForum. Page generated in 0.02153 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top