Home » Modeling » EMF » Persisting EStructuralFeature
| Persisting EStructuralFeature [message #493570] |
Tue, 27 October 2009 02:20  |
 Michael Spertus
Messages: 78
Registered: July 2009 |
Member |
|
|
I am writing an EMF application allows the user to specify which attribute is displayed. In order to remember this, one of my model classes has an attribute of type EStructuralFeature that contains the attribute (or reference) the user wants displayed. I have no problem creating the model or using the editor to store data for my model, including the right structural feature.
Unfortunately, when I load the data and try to use eGet to dereference the structural feature, it fails to recognize the attribute. The problem seems to be that while the name of the structural feature is filled in, other important fields like the index are not, so the eGet fails. If I programmatically fill in the EStructuralFeature with the same structural feature, it works, so the problem appears to be related to loading the persisted EStructuralFeature.
Is there anything more (or example code) that I need to load a persisted EStructuralFeature?
Thanks,
Mike
|
|
|
| Re: Persisting EStructuralFeature [message #493588 is a reply to message #493570] |
Tue, 27 October 2009 05:33  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Michael,
Comments below.
Michael Spertus wrote:
> I am writing an EMF application allows the user to specify which
> attribute is displayed. In order to remember this, one of my model
> classes has an attribute of type EStructuralFeature that contains the
> attribute (or reference) the user wants displayed. I have no problem
> creating the model or using the editor to store data for my model,
> including the right structural feature.
>
> Unfortunately, when I load the data and try to use eGet to dereference
> the structural feature, it fails to recognize the attribute. The
> problem seems to be that while the name of the structural feature is
> filled in, other important fields like the index are not, so the eGet
> fails.
Sounds like the proxy is failing to resolve. Is EObject.eIsProxy true?
> If I programmatically fill in the EStructuralFeature with the same
> structural feature, it works, so the problem appears to be related to
> loading the persisted EStructuralFeature.
>
> Is there anything more (or example code) that I need to load a
> persisted EStructuralFeature?
Generally not, but you've not told me anything that would hint at why
the proxy would fail to resolve. If you cast it to InternalEObject and
look at the eProxyURI, what's its value. If you're referirng to the
generated model, I'd expect <nsURI>#//<ClassName>/<FeatureName> and as
long as the package is register, that should resolve properly.
>
> Thanks,
>
> Mike
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Persisting EStructuralFeature [message #493720 is a reply to message #493588] |
Tue, 27 October 2009 16:36 |
Michael Spertus
Messages: 78
Registered: July 2009 |
Member |
|
|
Hi Ed,
eProxyURI is null, so things have already gone south. There is a URI in the persisted XML:
<summaryFeature xsi:type="ecore:EAttribute" href=" platform:/plugin/com.japaneselearningtools.tango.kanji/model /kanji.ecore#//kanji/glyph "/>
but it doesn't seem to end up in the object's eProxURI. ResolveProxies is true in the genmodel. What else should I look for?
Thanks for your help,
Mike
PS. The eclipse.org/forums page displays the above XML with extra spaces. There are actually no spaces in the href attribute.
[Updated on: Tue, 27 October 2009 16:38] Report message to a moderator |
|
| | | |
| Re: Persisting EStructuralFeature [message #494607 is a reply to message #494529] |
Sun, 01 November 2009 00:52 |
Michael Spertus
Messages: 78
Registered: July 2009 |
Member |
|
|
Hi Ed,
Thanks for all your help. See below.
| Ed Merks wrote on Sat, 31 October 2009 04:28 | Michael,
Comments below.
Michael Spertus wrote:
> I stepped through this in the debugger, and the problem seems to be
> that ResourceSetImpl.getResource fails to find the resource when
> passed the URI corresponding to "
> platform:/plugin/com.japaneselearningtools.tango.kanji/model
> /kanji.ecore ".
Again, are the spaces here intentional?
|
No, the web interface to Eclipse Community Forums seems to insert them on its own.
| Quote: | The call to getResource ought
to always produce a resource, but that resource may well fail to load if
the URI don't correspond to a real existing resource. Did you check all
the resources in the resource set, including each of their getErrors
contents?
> Do I have to tell it more about .ecore resources? I didn't do anything
> special in that regard.
Are you running stand alone. If so, yes you must register the resource
factory.
|
OK. Now I added
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "ecore", new EcoreResourceFactoryImpl());
(ignore the spaces) to my app and it gets closer but still no cigar.
It now finds and parses the kanji.ecore resource. It even resolves kanji/glyph to the corresponding EStructuralFeature from kanji.ecore, so eProxyURI is no longer set. However, the feature loaded from kanji.ecore still has a featureID of -1 (I verified this while iterating through the features of kanji.ecore during the resolve), which results in the same "glyph is not a valid feature" message.
All of the resources in the ResourceSet have empty "errors" ELists.
Any other thoughts?
Thanks again,
Mike
|
|
|
| Re: Persisting EStructuralFeature [message #494613 is a reply to message #494607] |
Sun, 01 November 2009 08:32 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Michael Spertus wrote:
> Hi Ed,
> Thanks for all your help. See below.
> Ed Merks wrote on Sat, 31 October 2009 04:28
>> Michael,
>>
>> Comments below.
>>
>> Michael Spertus wrote:
>> > I stepped through this in the debugger, and the problem seems to be
>> > that ResourceSetImpl.getResource fails to find the resource when >
>> passed the URI corresponding to " >
>> platform:/plugin/com.japaneselearningtools.tango.kanji/model >
>> /kanji.ecore ". Again, are the spaces here intentional?
>
> No, the web interface to Eclipse Community Forums seems to insert them
> on its own.
> Quote:
>> The call to getResource ought to always produce a resource, but that
>> resource may well fail to load if the URI don't correspond to a real
>> existing resource. Did you check all the resources in the resource
>> set, including each of their getErrors contents?
>> > Do I have to tell it more about .ecore resources? I didn't do
>> anything > special in that regard.
>> Are you running stand alone. If so, yes you must register the
>> resource factory.
>
> OK. Now I added
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto
> ryMap().put( "ecore", new EcoreResourceFactoryImpl());
> (ignore the spaces) to my app and it gets closer but still no cigar.
>
> It now finds and parses the kanji.ecore resource. It even resolves
> kanji/glyph to the corresponding EStructuralFeature from kanji.ecore,
> so eProxyURI is no longer set. However, the feature loaded from
> kanji.ecore still has a featureID of -1 (I verified this while
> iterating through the features of kanji.ecore during the resolve),
> which results in the same "glyph is not a valid feature" message.
That's computed when the getEAllStructuralFeatures of the containing
EClass is called. Why do you care?
>
> All of the resources in the ResourceSet have empty "errors" ELists.
>
> Any other thoughts?
It sounds like it's working.
>
> Thanks again,
>
> Mike
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Persisting EStructuralFeature [message #494632 is a reply to message #494613] |
Sun, 01 November 2009 13:33 |
Michael Spertus
Messages: 78
Registered: July 2009 |
Member |
|
|
Thanks Ed,
See below
| Ed Merks wrote on Sun, 01 November 2009 03:32 | Michael Spertus wrote:
> It now finds and parses the kanji.ecore resource. It even resolves
> kanji/glyph to the corresponding EStructuralFeature from kanji.ecore,
> so eProxyURI is no longer set. However, the feature loaded from
> kanji.ecore still has a featureID of -1 (I verified this while
> iterating through the features of kanji.ecore during the resolve),
> which results in the same "glyph is not a valid feature" message.
That's computed when the getEAllStructuralFeatures of the containing
EClass is called. Why do you care?
>
> All of the resources in the ResourceSet have empty "errors" ELists.
>
> Any other thoughts?
It sounds like it's working.
>
> Thanks again,
>
> Mike
|
The problem is that I get the "glyph is not a valid feature" message when I use it. Maybe I am using it incorrectly.
If k is a valid KanjiImpl object, k.eGet(deserialized structural feature) says that glyph is not a valid feature. However, k.eGet(kanjiPackage.Literals.KANJI__GLYPH) works fine (but hardwires my program to only use the glyph feature). How do I make the deserialized glyph structural feature work the same way as the literal?
[Updated on: Sun, 01 November 2009 21:46] Report message to a moderator |
|
|
| Re: Persisting EStructuralFeature [message #494669 is a reply to message #494632] |
Mon, 02 November 2009 05:37 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Michael,
Comments below.
Michael Spertus wrote:
> Thanks Ed,
> See below
> Ed Merks wrote on Sun, 01 November 2009 03:32
>> Michael Spertus wrote:
>>
>> > It now finds and parses the kanji.ecore resource. It even resolves
>> > kanji/glyph to the corresponding EStructuralFeature from
>> kanji.ecore, > so eProxyURI is no longer set. However, the feature
>> loaded from > kanji.ecore still has a featureID of -1 (I verified
>> this while > iterating through the features of kanji.ecore during the
>> resolve), > which results in the same "glyph is not a valid feature"
>> message.
>> That's computed when the getEAllStructuralFeatures of the containing
>> EClass is called. Why do you care?
>> >
>> > All of the resources in the ResourceSet have empty "errors" ELists.
>> >
>> > Any other thoughts?
>> It sounds like it's working.
>> >
>> > Thanks again,
>> >
>> > Mike
>
> The problem is that I get the "glyph is not a valid feature" message
> when I use it. Maybe I am using it incorrectly.
>
> If k is a valid KanjiImpl object, k.openGet(deserialized structural
> feature) says that glyph is not a valid feature. However,
> k.openGet(kanjiPackage.Literals.KANJI__GLYPH) works fine (but
> hardwires my program to only use the glyph feature). How do I make the
> deserialized glyph structural feature work the same way as the literal?
Typically when dealing with an arbitrary object one must ask the object
for the class, and use features of that class. I.e.,
eObject.eClass().getEAllStructuralFeatures().
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Persisting EStructuralFeature [message #494777 is a reply to message #494669] |
Mon, 02 November 2009 15:46 |
Michael Spertus
Messages: 78
Registered: July 2009 |
Member |
|
|
| Ed Merks wrote on Mon, 02 November 2009 |
Typically when dealing with an arbitrary object one must ask the object
for the class, and use features of that class. I.e.,
eObject.eClass().getEAllStructuralFeatures().
|
Hmm...I actually pass the feature to an EObservableMap, so that may be awkward. Again, using kanjiPackage.Literals.KANJI__GLYPH works fine. Is there a reasonable way to use the editor to persist a feature from an eCore model, and use those the same way (i.e., in an eGet()) as the corresponding literal?
[Updated on: Mon, 02 November 2009 16:34] Report message to a moderator |
|
| | |
| Re: Persisting EStructuralFeature [message #496559 is a reply to message #496552] |
Tue, 10 November 2009 14:23 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Michael,
Comments below.
Michael Spertus wrote:
> Ed Merks wrote on Mon, 02 November 2009 20:00
>> Given I don't have a lot of context for what your editor is doing,
>> it's hard to explain what you need to do.
>
> Here it is in a nutshell. Thanks very much for your patience, Ed.
>
> Suppose I have an EList of Person objects and wish to let the user
> persist which attribute they would like to sort the EList on in a
> "SortInformation" object as in the following model.
>
>
>
> The user uses the generated editor to create a SortInformation object.
> Here's one that says that people should be sorted based on height.
>
>
> If I create an inner class of SortImplementationImpl that looks
> something like:
>
> public class SortInformationImpl extends EObjectImpl implements
> SortInformation {
> public class MyComparator implements java.util.Comparator<Person> {
> @Override
> public int compare(Person o1, Person o2) {
> return
> ((Comparable)(o1.eGet(fieldToSortOn))).compareTo(o2.eGet(fie ldToSortOn));
> }
> }
> }
>
> It fails to run properly when instantiated from the my.sortfeature
> file shown above because the o1.eGet(deserialized height attribute)
> fails to compare two Person objects, saying "height is not a valid
> feature."
>
> This is very simplified from the actual application of course, but
> hopefully it gives the general idea and explains why it is a desirable
> thing to do.
>
> Does this make sense? Is there a way to support this sort of use case?
Be sure to get the feature to sort on from the eClass() of the actual
object you'll be manipulating. In the end this comes down to "how are
you setting" fieldToSortOn"? If you use "Load Resource..." to load a
*.ecore file and picking the feature from there, you won't be getting
the actual generate feature of the actual instance you're manipulating,
you'll be getting the development time clone of it instead and you won't
be able to use that instance on the actual generated model instances.
How are you populating the choices of feature?
>
> Thanks again for your time,
>
> Mike
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Goto Forum:
Current Time: Thu Apr 25 04:33:45 GMT 2024
Powered by FUDForum. Page generated in 0.03962 seconds |
] 
Search
Help
Register
Login
Home
