|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 09:47
| Ed Willink
Registered: July 2009
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.
Powered by FUDForum
. Page generated in 0.02100 seconds