Community
Participate
Working Groups
Currently the translator framework supports writing this EMF object model: ParentObject -> IntermediateObject -> ChildObject to this xml structure: <parent> <child>blah</child> </parent> by use of a DependencyTranslator. However it is not possible to support *this* xml structure: <parent child="blah"/> because of the way that the EMF2DOMAdapterImpl is written. Currently if you want to support an xml structure of this form, you can have no intermediate objects in your model. Other than it being simply the way that it's coded, it's not clear why one structure is supported but the other isn't.
I'm not really an expert in this, but... What exactly do you mean by IntermediateObject? Is that a child object contained in Parent which has a shared reference to Child? In general, it appears that the DOM_ATTRIBUTE style is only allowed with the simplest cases of atomic values and single references, no multis, no parent dependent objects, etc. Another half-implemented style is the COMMENT_FEATURE, which is addressed in bug 164246. My suggestion is that we make a matrix of allowable combinations of each Translator style, and also document how the styles are added automatically sometimes, like OBJECT_MAP and SHARED_REFERENCE, BOOLEAN_FEATURE, etc. And then make unit tests to back that up. I've not seen any unit tests for this framework, but I might not be looking in the right spots. Are there any? FWIW: I have code for EMF2DOMAdapter sitting here which enables multiple references in an attribute, (with spaces inbetween), e.g.: <cars> <car id="a" name="Toyota" licenseTag="1LVCLPS"/> <car id="b" name="Lexus" licenseTag="WTPRCKS"/> </cars> <carTransport cargo="a b"/> It's a fairly specific fix for the combination og attributes and multi's. Is this interesting for WTP, I can add it to the bug, or make a new one?
By intermediate object, I mean an object that lies in the reference path (which *can* be a containment path) from ParentObject to ChildObject. That is, the parent has no *direct* reference to the child. It only references the intermediate object, and the intermediate object has a reference to the child object. An example: Project -(defaults)-> DefaultsPolicy -(defaultSaveLocation)-> EString Currently, one cannot use the Translator framework to save this to an XML document of the form: <project defaultSaveLocation="C://foo"> ... But one *can* use the Translator framework to save this to an XML document of the form: <project <defaultSaveLocation>C://foo</defaultSaveLocation> ...
This is pretty close to the parallel case that I did for the multiple attributes support. The key point is that you don't need to deal with new adapters on the DOM side, so it's relatively straightforward. I still think we should make a decent unit test for the trickier parts of the Translator framework.
It turns out I will need this for the Mule IDE which I'm working on. So if I provide a patch and a test case in the M4 timeframe, will there be someone to review and possibly commit it?
I cannot reproduce this. If you describe how this doesn't work, I'll investigate further. Here's what I tried: I made an EMF model containing Project, DefaultsPolicy, with the Project(default:DefaultsPolicy) and DefaultsPolicy(defaultSaveLocation:EString) like described in the original description, and then defined the translators like this: private Translator PROJECT_DEFAULTS_SAVE_LOCATION = new DependencyTranslator("defaultSaveLocation", TEST_PACKAGE.getDefaultsPolicy_DefaultSaveLocation(), TEST_PACKAGE.getProject_Defaults(), DOM_ATTRIBUTE); protected Translator createProject() { GenericTranslator t = new GenericTranslator("project", TEST_PACKAGE.getRootThing_Project()); t.setChildren(new Translator[] { PROJECT_DEFAULTS_SAVE_LOCATION } ); return t; } And it worked out of the box, equally for 1.5.0 and for HEAD. I tried loading/saving, setting and unsetting in EMF, and it appears to just work. I'll attach my testcase, which loads this XML: <?xml version="1.0" encoding="UTF-8"?> <root-thing name="rootbeer" strings="a"> <project defaultSaveLocation="/home/jesper/bug160469"/> </root-thing> The case proceeds as follows (see uploaded TranslatorTest for details): // Load the XML mentioned above Resource wetp = loadResource(TranslatorTest.class.getResource("resource/bug160469.xml")); assertTrue(wetp.getContents().get(0) instanceof RootThing); RootThing rt = (RootThing)wetp.getContents().get(0); assertEquals("/home/jesper/bug160469", rt.getProject().getDefaults().getDefaultSaveLocation()); // Now clear the whole project node and reload rt.setProject(null); wetp = saveAndReLoad(wetp); RootThing rt2 = (RootThing)wetp.getContents().get(0); // It should still be gone! assertNull(rt2.getProject()); // Now recreate the Project and DefaultsPolicy rt2.setProject(WTPEMFTestFactory.eINSTANCE.createProject()); rt2.getProject().setDefaults(WTPEMFTestFactory.eINSTANCE.createDefaultsPolicy()); rt2.getProject().getDefaults().setDefaultSaveLocation("d:\\temp\\worksforme"); // And cycle that to disk and back wetp = saveAndReLoad(wetp); RootThing rt3 = (RootThing)wetp.getContents().get(0); assertEquals("d:\\temp\\worksforme",rt3.getProject().getDefaults().getDefaultSaveLocation()); // Still there. If we apply bug 169447 it will even work with multiple values inside the dependent (not multiple dependents, though). In my test Ecore model, I added (defaultMasks:0..* EInteger) and the XML looked like this: <project defaultSaveLocation="/home/jesper/bug160469" defaultMasks="1 2 4"/> Worked just fine (with the (updated) patch). By design, DependencyTranslator won't work with SourceLink, since that's an unrelated Translator subclass. If the dependency is changed to delegate the last part, this could be changed, but I'm not sure about the value of this. So, no references, only values.
Created attachment 56510 [details] Patch to enable setting a style in a DependencyTranslator constructor Just one more constructor which enables setting the translator style (plus comments)
Created attachment 56516 [details] Example project (ZIP file) demonstrating the feature This ZIP file demonstrates the test case which is mentioned in the comment. It works for both DOM and SAX. It requires the patch (convenience constructor overload)
Created attachment 56517 [details] mylar/context/zip
Created attachment 56518 [details] ZIP file containing example for multiple values in attribute The patch in bug 169447 must be applied for this to work.
Loading and saving a static model was never a problem for me. What failed for me was, while the model is loaded: - Changing the EMF simple value and having the document change along with it. *and* - Changing the document attribute and having the EMF simple value change along with it. (One direction worked, but the other didn't; I can't recall which.) It isn't clear from the above description that that was tested. Was it?
(In reply to comment #10) > Loading and saving a static model was never a problem for me. What failed for > me was, while the model is loaded: That's not how I read it - I rather saw it to mean that there was no support at all. Then again, English is not my first language. > - Changing the EMF simple value and having the document change along with it. > *and* > - Changing the document attribute and having the EMF simple value change along > with it. > > (One direction worked, but the other didn't; I can't recall which.) Was this spotted in the context of EMF2DOMSSE? > It isn't clear from the above description that that was tested. Was it? I'm (indirectly) coverering the EMF->DOM propagation but then reading it back rather than responding to changes. So the DOM->EMF propagation isn't tested. I'm guessing that the bug is possibly about an adapter on the DOM object which doesn't pick up the attribute change (DOM->EMF propagation). That might affect other attribute changes as well, although that's just a guess at the moment. I will extend the test case to meddle with the DOM directly. My test case is only as precise as the bug report ;-)
(In reply to comment #11) > > Loading and saving a static model was never a problem for me. What failed for > > me was, while the model is loaded: > > That's not how I read it - I rather saw it to mean that there was no support at > all. Then again, English is not my first language. > Very understandable. Since I assumed that the primary function of the translator framework is the real-time synchronization of document and model, then not supporting that was "no support". Perhaps I'm confusing the purpose of the translator framework with *my* purposes. :) > > - Changing the EMF simple value and having the document change along with it. > > *and* > > - Changing the document attribute and having the EMF simple value change along > > with it. > > > > (One direction worked, but the other didn't; I can't recall which.) > > Was this spotted in the context of EMF2DOMSSE? > Yes. That is what we're using. > I'm guessing that the bug is possibly about an adapter on the DOM object which > doesn't pick up the attribute change (DOM->EMF propagation). That might affect > other attribute changes as well, although that's just a guess at the moment. I'm almost positive (after debugging) that that is the case. In the case of dependent objects and elements, the correct adapter is added, but not in the case of dependent objects and attributes.
(In reply to comment #12) > Very understandable. Since I assumed that the primary function of the > translator framework is the real-time synchronization of document and model, > then not supporting that was "no support". Perhaps I'm confusing the purpose > of the translator framework with *my* purposes. :) Not really. I use it for the same purpose. I'll have a look why the adapter isn't catching.
Created attachment 56688 [details] New test case which hits XML2DOMSSE It still works fine for me with the adapter firing and all. Run the test DOMSSETranslatorTest as a Plugin-in Unit Test, and it should pass (does for me, at least). I tried both creating and updating the attribute, both worked. So, WORKSFORME, luckily. Mabye some other detail changed, like the SSE change in 2004 to propagate attribute changes as STRUCTURE_CHANGED.
Jesper, what stream is the patch for, so that I can apply it in my workspace?
(In reply to comment #15) > Jesper, what stream is the patch for, so that I can apply it in my workspace? It's for HEAD, but should also apply with little fuzz to the current 1.5 stream. BTW, the test case plugin assumes Java 5.
Changing target to M6
This patch had one JUnit failure - testDeleteMultipleDependency I need to investigate that more before recommending the patch.
We're running out of time for WTP 2.0, so I am decommiting this.
(In reply to comment #19) > We're running out of time for WTP 2.0, so I am decommiting this. > Carl, is there a possibility to get this reviewed again for 3.1 time frame? It appears to be one of those items that is sitting in limbo.
Will have to retry the tests, but if things still fail, this bug will most likely be marked helpwanted.
Honestly: I don't have any time to update the test for this bug.
