Best place to store a derived model and to make it referable from the DSL [message #1778041] |
Fri, 08 December 2017 09:12  |
Eclipse User |
|
|
|
Hi guys,
currently I'm using the IDerivedStateComputer to instantiate a derivedModel from my DSL. The derived model is defined by an external EMF-Metamodel (lets call it DerivedModel) and the created instance is added to the XtextResource (resource.contents) of my DSL. The derived meta model is different from the meta model of my DSL.
Now I need the following possibility:
If the User saves his .myDsl file then the derived model should be also stored.
Next it should be possible to include (via include keyword) the derived model from another .myDsl file and to refer to the derived elements.
1) What is the best place to store the model? The IGenerator?
2) How can I load these resources? So what do I need to get access to it?
PS:
=> I'm not using a Standalone Setup. So I have an IDE
=> Please be lenient as I am a beginner :)
Many thanks and have a nice weekend!
|
|
|
|
|
Re: Best place to store a derived model and to make it referable from the DSL [message #1778078 is a reply to message #1778065] |
Sat, 09 December 2017 04:47   |
Eclipse User |
|
|
|
Hi
Further questions:
How many *.dsl files do you expect per project in the worst realistic case? < 10 => don't use a folder hierarchy. > 1000 => use a folder hierarchy.
Do you intend to persist your derived files in e.g. GIT? If re-generation is difficult, slow, unrepeatable or undesirable then putting them in GIT may be a good idea, but it bloats your GIT repo and requires every edit to have its derived commit.
If files are persisted then you probably want to store them as siblings of their sources, perhaps in the same tree, perhaps in a parallel tree such as xtend-gen.
If derived content is regenerated on demand, your persistence problem goes away since each consumer does the derivation independently.
For OCL, I have a kind of hybrid approach. If XXX.YYY is imported, it is converted to OCL Abstract Syntax form by the loader. If XXX.YYY.oclas is imported, the derived form is available directly if the file exists, otherwise it is derived from XXX.YYY. The ResourceFactory for *.oclas my therefore delegate to a wrapped *.YYY Resource Factory when necessary.
If you rely on regenerated content you need to take great care that regeneration is deterministic; no dependence on accidental Set ordering, garbage collection timing. xmi:id referencing must be robust. You might care to look at Eclipse OCL's Locally Unique Semantically Sensitive Identifier generation algorithms that give short predictable xmi:id values. See http://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/plugins/org.eclipse.ocl.pivot/src/org/eclipse/ocl/pivot/internal/resource/LUSSIDs.java
Maybe I'm missing your point completely. Sorry. I have no idea what you mean by storing content in an IGenerator since I have never knowingly used an IGenerator.
Regards
Ed Willink
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.51604 seconds