|
| Re: EMFModelInferrer [message #1748781 is a reply to message #1748765] |
Mon, 28 November 2016 15:08   |
|
Tom,
sorry, I don't get the reason of your use case. But if you would like to have EMF generated code with custom Xbase operations, then Xcore is exactly doing this and you should go with that instead of creating your own DSL.
~Karsten
|
|
|
| Re: EMFModelInferrer [message #1748790 is a reply to message #1748781] |
Mon, 28 November 2016 15:43 |
 Thomas Kohler
Messages: 15
Registered: November 2016 |
Junior Member |
|
|
Hello Karsten,
The use case is a technical simple DSL to describe Business Logic in form of part-trees (heavy weight pojo's for which I want to use EMF based classes to get Persistence, correct containment/reference behaviour). The DSL Users don't have technical background, so xcore would be to much for them.
To fulfill the technical background we already wrote a complex Framework for the runtime side - inspired by EMF, but not EMF. All Business logic is currently defined in a kind of Configuration Tool (SWT and EMF based) which generates all Business Classes (using old oAW xpand and partially xtend) and also all needed resources like XHTMLs (JSF), Persistence, Mappings, ... . So you can model a new BusinessObject together with it's gui layout, press generate and use it immediatly via tomcat and your browser.
My intention for a future major release is to replace the Configuration Tool with a DSL (which can be used like any language in the Eclipse IDE), build an additional Configuration Tool which looks like the old one but onto the new EMF Model of the DSL instead of our old configuration model (for the business logic modelling people) use xbase instead of our own antlr based 4gl grammar for operations and store the configurations resources using the DSL parser/serializer instead of XMI-XML as before. So changes in the "code" wil be reflected in the Config Tool and vice versa. At the moment our technical Team don't want to use the Config Tool (to less possibilities to express themself) and the modelling people are not skilled technical enough to use Java together with our framework. The new approach would fulfill the needs of both fractions.
On the runtime side (which contains and runs the generated parts) I want to switch to EMF instead of using our own model framework and enrich the EMF generated classes with the parts of business logic out of the DSL. If we could manage this, we would have a solid Configuration language (xbase) and a solid model framework background (EMF).
To bring it together: A simple to use DSL should generate a technical mature model which fits into out base framework... 
regards, Tom
|
|
|
| Re: EMFModelInferrer [message #1748818 is a reply to message #1748790] |
Tue, 29 November 2016 04:52 |
|
Thanks Thomas for the explanation. The reason I was asking is because Xcore does quite some effort to create such enhanced EMF classes and you should leverage this if possible. Xcore's org.eclipse.emf.ecore.xcore.generator package contains the stuff that adapts Xcore's models to EMF generator models. If you would have to build this for your own DSL, this is a starting point.
If possible, I would avoid to replicate the code and maintain it for a custom DSL. Instead I would reuse Xcore. Xcore would produce the enriched EMF classes as you require, with custom Xbase operations. I understand that you don't want to have the Xcore syntax for your DSL, but how about implementing a small IGenerator that creates .xcore files from your DSL files and let Xcore do the EMF codegen?
Is this a way to go for you?
|
|
|
Powered by
FUDForum. Page generated in 0.01711 seconds
] 
Search
Help
Register
Login
Home
