Home » Modeling » EMF » Obtaining edit Type Text from eClass
| Obtaining edit Type Text from eClass [message #519201] |
Mon, 08 March 2010 00:33  |
 Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
One that sounds like it should be easy but I can't figure it out. For a non-EMF generated editor, I want to get the appropriate type text (i.e. "Inventory Item" for "ABCInventoryItem") that has been defined in the generated ..edit plugin.properties. But all of the base implementations from ItemProviderAdapter#getTypeText to getResourceLocator, etc.. are protected in the base classes. How can I get this for an arbitrary eClass and associated Item Provider?
thanks,
Miles
[Updated on: Mon, 08 March 2010 03:39] Report message to a moderator |
|
|
| Re: Obtaining edit Type Text from eClass [message #519215 is a reply to message #519201] |
Mon, 08 March 2010 05:44  |
|
Hi Miles,
I think you need an AdapterFactory like in AdapterFactoryLabelProvider:
/**
* This implements {@link ILabelProvider}.getText by forwarding it to
an object that implements
* {@link IItemLabelProvider#getText IItemLabelProvider.getText}
*/
public String getText(Object object)
{
// Get the adapter from the factory.
//
IItemLabelProvider itemLabelProvider =
(IItemLabelProvider)adapterFactory.adapt(object, IItemLabelProviderClass);
return
itemLabelProvider != null ?
itemLabelProvider.getText(object) :
object == null ?
"" :
object.toString();
}
DTH?
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 08.03.2010 01:33, schrieb Miles Parker:
> One that sounds like it should be easy but I can't figure it out. For
> a non-EMF generated editor, I want to get the appropriate type text
> (i.e. "Inventory Item" for "ABCInventoryItem") that has been defined
> in the generated ..edit. But all of the base implementations from
> getTypeText to getResourceLocator are protected in the base classes.
> How can I get this for an arbitrary eClass?
>
> thanks,
>
> Miles
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: Obtaining edit Type Text from eClass [message #519412 is a reply to message #519289] |
Mon, 08 March 2010 18:14 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Hi guys,
Thanks. See response to each below..
| Quote: |
Eike Stepper wrote:
> I think you need an AdapterFactory like in AdapterFactoryLabelProvider:
|
To be clear, I'm interested in getting the class / type name, not the object name.
| Ed Merks wrote on Mon, 08 March 2010 07:00 | Miles,
You'd need to get it directly from XyzEditPlugin.INSTACE.getText("_UI_"
+ eClass.getName() + "_type")
|
That's kind of what I was afraid of. The issue is that that prevents anyone from writing an editor that can make use of arbitrary meta-models and still have access to the (internationalized) plugin information. I got into looking at this because I noticed that EEF was using it's own setup for defining type names and I thought, "why can't they just use the same definitions as in the edit plugin?" (Actually, they could, with a little extra model information but that's not the point  )
It seems that the only change necessary to make this possible would be to have the resource locator and getTypeText visibility changed, or is there a technical issue I'm missing here? I realize that this wouldn't work for cases where there might be more than one set of edits / editors defined, but it should work in common cases. I am after all able to get the custom object name info, so why not the custom type info?
I'd considered doing this in a hacky way by populating a model with some sample defaults, getting the create child text using the item provider, and then parsing the "Create.." text back to the type name, but that seems like a lot to go through..
cheers,
Miles
|
|
|
| Re: Obtaining edit Type Text from eClass [message #519418 is a reply to message #519412] |
Mon, 08 March 2010 18:26 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Miles,
Comments below.
Miles Parker wrote:
> Hi guys,
>
> Thanks. See response to each below..
>
> Quote:
>> Eike Stepper wrote:
>> > I think you need an AdapterFactory like in
>> AdapterFactoryLabelProvider:
>
>
> To be clear, I'm interested in getting the class / type name, not the
> object name.
>
> Ed Merks wrote on Mon, 08 March 2010 07:00
>> Miles,
>>
>> You'd need to get it directly from
>> XyzEditPlugin.INSTACE.getText("_UI_" + eClass.getName() + "_type")
>
>
> That's kind of what I was afraid of. The issue is that that prevents
> anyone from writing an editor that can make use of arbitrary
> meta-models and still have access to the (internationalized) plugin
> information. I got into looking at this because I noticed that EEF was
> using it's own setup for defining type names and I thought, "why can't
> they just use the same definitions as in the edit plugin?" (Actually,
> they could, with a little extra model information but that's not the
> point :))
> It seems that the only change necessary to make this possible would be
> to have the resource locator and getTypeText visibility changed, or is
> there a technical issue I'm missing here?
You have to have an instance to use these methods, but you'd like the
information given just the metamodel I guess...
> I realize that this wouldn't work for cases where there might be more
> than one set of edits / editors defined, but it should work in common
> cases. I am after all able to get the custom object name info, so why
> not the custom type info?
It seems not dependent on the instance and as something only seemed only
used within the instance.
>
> I'd considered doing this in a hacky way by populating a model with
> some sample defaults, getting the create child text using the item
> provider, and then parsing the "Create.." text back to the type name,
> but that seems like a lot to go through..
That wouldn't work for abstract types...
>
> cheers,
If you know the plugin-id you could get the plugin that way and load the
resource from it... There's no registry for that... Not sure a good
general approach for this...
>
> Miles
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Obtaining edit Type Text from eClass [message #519430 is a reply to message #519418] |
Mon, 08 March 2010 19:07 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Ed, thanks... see below.
| Ed Merks wrote on Mon, 08 March 2010 13:26 | Miles,
> It seems that the only change necessary to make this possible would be
> to have the resource locator and getTypeText visibility changed, or is
> there a technical issue I'm missing here?
You have to have an instance to use these methods, but you'd like the
information given just the metamodel I guess...
|
Yes, but it would work fine to have to provide an instance as well, as obviously a utility method could simply instantiate an instance of the eClass.
| Quote: | > I realize that this wouldn't work for cases where there might be more
> than one set of edits / editors defined, but it should work in common
> cases. I am after all able to get the custom object name info, so why
> not the custom type info?
It seems not dependent on the instance and as something only seemed only
used within the instance.
|
Ah. I was assuming that it was always dependent on the instance. Shouldn't every instance have one and only one concrete constant type associated with it?
| Quote: | > I'd considered doing this in a hacky way by populating a model with
> some sample defaults, getting the create child text using the item
> provider, and then parsing the "Create.." text back to the type name,
> but that seems like a lot to go through..
That wouldn't work for abstract types...
|
I only care about concrete types. So I'd be perfectly happy passing in an instance of the type. For a use case, what I want to do here is get a list of all possible type names that could be used to populate a given feature reference. In other words, just like what is done with the create child text, but I just want the type names.
| Quote: | If you know the plugin-id you could get the plugin that way and load the
resource from it... There's no registry for that... Not sure a good
general approach for this...
|
Yeah.. it's not a problem for me, because I know what the plugin is for my own usages so I can get the resource locator, but I'm thinking in terms of making the capability more general.
|
|
|
| Re: Obtaining edit Type Text from eClass [message #519434 is a reply to message #519430] |
Mon, 08 March 2010 19:14 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Miles,
Comments below.
Miles Parker wrote:
> Ed, thanks... see below.
>
> Ed Merks wrote on Mon, 08 March 2010 13:26
>> Miles,
>> > It seems that the only change necessary to make this possible would
>> be > to have the resource locator and getTypeText visibility changed,
>> or is > there a technical issue I'm missing here? You have to have an
>> instance to use these methods, but you'd like the information given
>> just the metamodel I guess...
>
>
> Yes, but it would work fine to have to provide an instance as well, as
> obviously a utility method could simply instantiate an instance of the
> eClass.
Not if it's abstract.
>
> Quote:
>> > I realize that this wouldn't work for cases where there might be
>> more > than one set of edits / editors defined, but it should work in
>> common > cases. I am after all able to get the custom object name
>> info, so why > not the custom type info?
>> It seems not dependent on the instance and as something only seemed
>> only used within the instance.
>
>
> Ah. I was assuming that it was always dependent on the instance.
> Shouldn't every instance have one and only one concrete constant type
> associated with it?
The point is it doesn't depend on the state of the instance. It's just
information about the model.
>
> Quote:
>> > I'd considered doing this in a hacky way by populating a model with
>> > some sample defaults, getting the create child text using the item
>> > provider, and then parsing the "Create.." text back to the type
>> name, > but that seems like a lot to go through..
>> That wouldn't work for abstract types...
>
>
> I only care about concrete types. So I'd be perfectly happy passing in
> an instance of the type. For a use case, what I want to do here is get
> a list of all possible type names that could be used to populate a
> given feature reference. In other words, just like what is done with
> the create child text, but I just want the type names.
I see.
>
> Quote:
>> If you know the plugin-id you could get the plugin that way and load
>> the resource from it... There's no registry for that... Not sure a
>> good general approach for this...
>
>
> Yeah.. it's not a problem for me, because I know what the plugin is
> for my own usages so I can get the resource locator, but I'm thinking
> in terms of making the capability more general.
Yes, I'm just not sure how best to generalize it at this point...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Obtaining edit Type Text from eClass [message #519440 is a reply to message #519434] |
Mon, 08 March 2010 19:59 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Please see below..
| Ed Merks wrote on Mon, 08 March 2010 14:14 |
> Yeah.. it's not a problem for me, because I know what the plugin is
> for my own usages so I can get the resource locator, but I'm thinking
> in terms of making the capability more general.
Yes, I'm just not sure how best to generalize it at this point...
|
Yeah, I'm out of ideas on the user side as well. Form the framework side, I guess I'm still not sure what wouldn't work about making say the ItemProviderAdapter#getTypeText() or (probably better and more general) ItemProviderAdapter#getResourceLocator() public? I mean, I can see why design wise we would want to lock that down, but as these are all public for the actual generated item providers, it would enable a bunch of nice dynamic capability to have these be usable from outside of direct subclasses..
|
|
| |
| Re: Obtaining edit Type Text from eClass [message #519444 is a reply to message #519440] |
Mon, 08 March 2010 15:34 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050002060306060203000607
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Miles,
Comments below.
Miles Parker wrote:
> Please see below.. :)
>
> Ed Merks wrote on Mon, 08 March 2010 14:14
>> > Yeah.. it's not a problem for me, because I know what the plugin is
>> > for my own usages so I can get the resource locator, but I'm
>> thinking > in terms of making the capability more general.
>> Yes, I'm just not sure how best to generalize it at this point...
>
>
> Yeah, I'm out of ideas on the user side as well. Form the framework
> side, I guess I'm still not sure what wouldn't work about making say
> the ItemProviderAdapter#getTypeText()
It's not currently API so one would need to an implementation class to
get at this. Also, you can't just make a protected method public and
assume this won't break downstream clients who might have overridden it
with a protected method.
> or (probably better and more general)
> ItemProviderAdapter#getResourceLocator() public?
Yes, though the same reasoning applies here.
> I mean, I can see why design wise we would want to lock that down, but
> as these are all public for the actual generated item providers, it
> would enable a bunch of nice dynamic capability to have these be
> usable from outside of direct subclasses..
Finally an idea: this approach in item provider adapter could be
implemented in an external utility method.
protected ResourceLocator getResourceLocator(Object anyObject)
{
if (adapterFactory instanceof ComposeableAdapterFactory)
{
Object adapter =
((ComposeableAdapterFactory)adapterFactory).getRootAdapterFa ctory().adapt(anyObject,
IItemLabelProvider.class);
if (adapter instanceof ResourceLocator)
{
return (ResourceLocator)adapter;
}
}
return getResourceLocator();
}
I.e., get the item provider that produces labels, check if it implements
ResourceLocator, which everything derived from ItemProviderAdapter does,
and use that to fetch the label...
--------------050002060306060203000607
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Miles,<br>
<br>
Comments below.<br>
<br>
<br>
Miles Parker wrote:
<blockquote cite="mid:hn3kvq$d03$1@build.eclipse.org" type="cite">Please
see below.. :)
<br>
<br>
Ed Merks wrote on Mon, 08 March 2010 14:14
<br>
<blockquote type="cite">> Yeah.. it's not a problem for me,
because I know what the plugin is > for my own usages so I can get
the resource locator, but I'm thinking > in terms of making the
capability more general.
<br>
Yes, I'm just not sure how best to generalize it at this point...
<br>
</blockquote>
<br>
<br>
Yeah, I'm out of ideas on the user side as well. Form the framework
side, I guess I'm still not sure what wouldn't work about making say
the ItemProviderAdapter#getTypeText()</blockquote>
It's not currently API so one would need to an implementation class to
get at this. Also, you can't just make a protected method public and
assume this won't break downstream clients who might have overridden it
with a protected method.<br>
<blockquote cite="mid:hn3kvq$d03$1@build.eclipse.org" type="cite"> or
(probably better and more general)
ItemProviderAdapter#getResourceLocator() public? </blockquote>
Yes, though the same reasoning applies here.<br>
<blockquote cite="mid:hn3kvq$d03$1@build.eclipse.org" type="cite">I
mean, I can see why design wise we would want to lock that down, but as
these are all public for the actual generated item providers, it would
enable a bunch of nice dynamic capability to have these be usable from
outside of direct subclasses..
<br>
</blockquote>
Finally an idea: this approach in item provider adapter could be
implemented in an external utility method.<br>
<blockquote><small> protected ResourceLocator
getResourceLocator(Object anyObject)<br>
{<br>
if (adapterFactory instanceof ComposeableAdapterFactory)<br>
{<br>
Object adapter =
((ComposeableAdapterFactory)adapterFactory).getRootAdapterFa ctory().adapt(anyObject,
IItemLabelProvider.class);<br>
if (adapter instanceof ResourceLocator)<br>
{<br>
return (ResourceLocator)adapter;<br>
}<br>
}<br>
<br>
return getResourceLocator();<br>
}</small><br>
</blockquote>
I.e., get the item provider that produces labels, check if it
implements ResourceLocator, which everything derived from
ItemProviderAdapter does, and use that to fetch the label...<br>
</body>
</html>
--------------050002060306060203000607--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
Goto Forum:
Current Time: Fri Apr 26 11:12:02 GMT 2024
Powered by FUDForum. Page generated in 0.04325 seconds |
] 
Search
Help
Register
Login
Home
