Community
Participate
Working Groups
I have been chasing a problem where my EEF code generation results in code which fails to compile. The problem code appears to involve issues with an EMF model representing Strings vs EStrings. I have been able to recreate the problem in the Library Tutorial when generating the EMF model from an XML schema. Here are the steps: 1) I followed the 'Generating an EMF Model using XML Schema' tutorial (http://help.eclipse.org/kepler/topic/org.eclipse.emf.doc/tutorials/xlibmod/xlibmod.html?cp=17_1_2) and generated the EMF editor. 2) I then followed http://wiki.eclipse.org/EEF/Tutorials/First_Generation to create the EEF code. 3) The generated code has two types of issues (ex: BookPropertiesEditionComponent.java): a) There is an incomplete import statement: // Start of user code for imports import ; b) The first parameter in the following method call is missing a parameter: if (isAccessible(LibraryViewsRepository.Book.Properties.title_)) basePart.setTitle_(EEFConverterUtil.convertToString(, book.getTitle())); If I perform the same steps but use the Rose model (library.mdl) to generate the EMF model, the EEF generation is fine. PS: I will attach the model, edit, and editor projects for both approaches (mdl -> emf and xsd -> emf), as well as details of my Eclipse installation. This is impacting my ability to move a product I am responsible up from 1.0.1 EEF which relies on generation of the EMF model from schemas.
Created attachment 238016 [details] model, edit, editor project for EMF from a mdl file These projects exhibit successful EEF generation from a EMF model which was created from the library.mdl file.
Created attachment 238017 [details] model, edit, editor project for EMF created from an xsd These projects exhibit unsuccessful EEF generation from a EMF model which was created from the library.xsd file.
Created attachment 238018 [details] My Eclipse configuration details
Hi, As you can see, the ecore model converted from XSD is more complex than the one from mdl. We did not experiment an EEF generation from ecore produced that way, so i suspect that the EEF generation is disturbed by the Metadata in the Ecore file. i let Goulwen explores this, since i have no more time to be involved in the EEF development for now.
(In reply to Stephane Bouchet from comment #4) > Hi, > > As you can see, the ecore model converted from XSD is more complex than the > one from mdl. > We did not experiment an EEF generation from ecore produced that way, so i > suspect that the EEF generation is disturbed by the Metadata in the Ecore > file. > > i let Goulwen explores this, since i have no more time to be involved in the > EEF development for now. Is there any idea when this can be looked at? I need to make a decision on how and if our product will be migrated from 1.0 EEF so it can run on Eclipse 4.3. If it isn't going to be looked at I may need to give up on EEF.
(In reply to John Palof from comment #0) > ... > 3) The generated code has two types of issues (ex: > BookPropertiesEditionComponent.java): > ... > b) The first parameter in the following method call is missing a parameter: > if (isAccessible(LibraryViewsRepository.Book.Properties.title_)) > basePart.setTitle_(EEFConverterUtil.convertToString(, > book.getTitle())); > ... These issues are a critical problem for me, so I have started to attempt to alter the templates today. For example, I have modified textControl.mtl changing from using: [editionElement.metamodelTypeGetter()/] to [editionElement.metamodelGetter()/].getEAttributeType() based on noticing that things were working in the component's validateValue method. However, I am sure I am attacking the symptom and not the cause. QUESTIONS: 1) How bad of an idea is it to tactically address this at the mtl level? 2) Any ideas on why editionElement.metamodelTypeGetter() would be returning an empty string? I guess there are problems with handling "String" from xsd generated EMF rather than the "EString" that would be coming from a Rose model generated EMF?
YES
