Eclipse Community Forums: TMF (Xtext) » Best place to store a derived model and to make it referable from the DSL

Home » Modeling » TMF (Xtext) » Best place to store a derived model and to make it referable from the DSL(Best place to store a derived model and to make it referable from the DSL)

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 #1778049 is a reply to message #1778041]

Fri, 08 December 2017 10:48

Eclipse User

Hi

It rather depends on your lifecycle. Consider some similar scenarios.

The author of one *.java file can automatically derive (compile) a corresponding *.class file. Another *.java file can easily reference the first *.java file once the second author has mastered the magic of classpaths.

Xtend as a Java extension, and I suspect some DSL generators can have similar ergonomic ease.

However you mention derivedModel, which is a whole different can of worms. EMF has no equivalent of a modelpath. Rather there are model registrations and platform:/resource / platform:/plugin fallbacks to accomodate plugin/project hosting. It is not easy for one modeling project to refer to another modeling project in both OSGI and non-OSGI contexts. UML introduces a pathmap: concept for its profiles. QVTo has its own model registrations. Generally there is poor modeling project commonality.

If you really need the 'model' rather than 'java' approach, how often is the referenced file edited in comparison to the referencing file? If very rare, then perhaps you can live with a plugin installation. If frequent you may need to think harder.

'java' and 'class' files normally live in a disciplined package hierarchy that the classpath supervises.

'model's can do the same, but putting them in a "model" folder is very common. A hierarchy for models works poorly with Maven/Tycho since you need to strip prefixes that vary for source/packaged files.

Regards

Ed Willink

Re: Best place to store a derived model and to make it referable from the DSL [message #1778065 is a reply to message #1778049]

Fri, 08 December 2017 15:11

Eclipse User

Hi Ed,

I have the following scenario:

With my DSL it's possible to describe some requirements and the DSL also support loops and functions to repeat requirements. In the IDerivedStateComputer I build an instance of a derived model where all the loops and functions are resolved and where I add further informations. So at the end the derived model represents the document with all requirements where the loops and functions are resolved.

Now the user can write many requirement documents in the IDE. From a requirment document he should have the possibility to include other requirement documents and to refer to these requirements.

So at the end the derived model of a requirement document have to persist as soon as the user saves it.

My first idea was to store the derived model as XMI and to load this XMI file when another requirement document includes it.

Basically it should be similar to the following blog https://typefox.io/linking-xtext-models-with-other-emf-models, or not?

But sofar I have no idea where to persist/store the derived instance (maybe in IGenerator?) and what I need to load these resources when another requirement document includes them via an include keyword.

I would be so happy if I could get some tips in which classes I have to look and what the rough steps would be. Currently I have not really an idea where to start.

To your question: The referenced file is not so often edited. Okay for sure it can happen that the user has two open requirement documents, where one refers to the other one. But in the end, it will suffice to save the derived model as soon as the referenced document is saved.

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

Re: Best place to store a derived model and to make it referable from the DSL [message #1778114 is a reply to message #1778078]

Sun, 10 December 2017 12:58

Eclipse User

Hi,

I expect < 500. We plan to use SVN and the user has to commit the files.

I think to regenerate the derived state on demand would be a good idea! But what would be the best place to load the imported DSL-Files and to regenerate the derived model?

Are there some Xtext-Classes where I can implement such a regeneration??

Many thanks for you tips!!!! I will take a look into you git link!!

To your last question I have no idea what you mean by storing content in an IGenerator since I have never knowingly used an IGenerator

My first idea was to use the IGenerator to add the derived instance to a resourceSet and to store it as XMI-Format.

But I don't need this approach when I would use your regeneration approach!

Whish you a nice Sunday!

Re: Best place to store a derived model and to make it referable from the DSL [message #1778136 is a reply to message #1778114]

Mon, 11 December 2017 02:56

Eclipse User

Sounds strange. The IDerivedStateComputer is hooked into the resource's lifecycle such that it creates the derived model on first access after loading and updates it (in fact deletes and reconstructs it) when the original model changes. So a derived model is something that can be fully derived from the original model, as such storing is redundant. The only reason to store it may be caching.

From an EMF perspective, the model and the derived model are equal members of the resource. Loading and accessing the resource instantiates the derived model.

What you describe feels more like an model to model transformation that should be hooked in via the IGenerator hook.

Re: Best place to store a derived model and to make it referable from the DSL [message #1778151 is a reply to message #1778136]

Mon, 11 December 2017 05:20

Eclipse User

Hi Jan,

thanks for your hint. But what would be the necessary steps to make the elements of the transformed model referable, when I would generate it in the IGenerator?

So at the end I need the possibility to refer to such a transformed model.

Re: Best place to store a derived model and to make it referable from the DSL [message #1778153 is a reply to message #1778151]

Mon, 11 December 2017 05:46

Eclipse User

The problem is that a xtext builder does not see the files it generates so you would need a second builder that touches the files from the first builder
So that they get built again

But as Jan and I said: why not iderivedstatecomputer

Re: Best place to store a derived model and to make it referable from the DSL [message #1778154 is a reply to message #1778153]

Mon, 11 December 2017 05:47

Eclipse User

No Message Body

Re: Best place to store a derived model and to make it referable from the DSL [message #1778155 is a reply to message #1778154]

Mon, 11 December 2017 05:49

Eclipse User

Hi

Oops...the wonders of FUDforum.

I'm not sure since I use custom name resolution.

But Xtext tries hard to be helpful for standard use cases, and inter-file referencing is a very common use case. It probably just works. Look for any example that has an 'import'.

Regards

Ed Willink

Re: Best place to store a derived model and to make it referable from the DSL [message #1778158 is a reply to message #1778153]

Mon, 11 December 2017 06:25

Eclipse User

Currently I do it like this:

I create my derived instance (defined by an external meta model) in the IDerivedState Computer and add it to the content of my resource. This makes it possible to refer to the elements of my derived model.

Now the user needs the possibility to include other .mydsl files (average <5 includes) from the current XXX.mydsl file (for example with an include keyword). But for this case I have also to create (regenerate) the derived instances for the included files and the chance to refer to the elements of the derived instances. What would be the best place to do this?

The reasons for the derived model are described here

https://www.eclipse.org/forums/index.php/t/1090180/

Re: Best place to store a derived model and to make it referable from the DSL [message #1778160 is a reply to message #1778158]

Mon, 11 December 2017 07:12

Eclipse User

am not sure if i understand your include "thing"

Re: Best place to store a derived model and to make it referable from the DSL [message #1778163 is a reply to message #1778160]

Mon, 11 December 2017 07:51

Eclipse User

Hi Christian,

for instance I have the file YYY.mydsl:


...

requirement AA {
   ...
}

// in the derived model the loop is resolved to requirement AC1, AC2, AC3
for(1...3) { 
   requirement AC {
       ...
   }
}

and I have the file XXX.mydsl that includes YYY.mydsl:

#include YYY.mydsl as YFile

   requirement A {
      ...
   }
   requirement B {
        description "In this description I refer to requirement" + A;
        description "In this description I refer to an requirement of the resolved for   loop from the file YYY.mydsl" + YFile.AC1 + "or" + YFile.AC2 + "or" + YFile.AC3; 
   }

That mean if I include YYY.mydsl then I also have to create the derived instance of the included file, so that I can refer to AC1, AC2, AC3.

Currently I have no idea what's the best way to implement such a behavior and where to start.

Please let me know if you need more information.

And again, many thanks for you help/tips !!! =)

PS: Instead of using #include ... as YFile it would be nice to have some kind of packages.

Re: Best place to store a derived model and to make it referable from the DSL [message #1778168 is a reply to message #1778163]

Mon, 11 December 2017 08:09

Eclipse User

i dont understand this.
why not simply do the m2m where stuff is defined?
then you can refer to the stuff and the derived stuff in the other file

Re: Best place to store a derived model and to make it referable from the DSL [message #1778171 is a reply to message #1778168]

Mon, 11 December 2017 08:24

Eclipse User

Sorry, what do you mean with not simply do the m2m where stuff is defined?

Maybe it's really simple and I only think it's complicated.

That's a disadvantage if you're a beginner :D
Unfortunately I'm a beginner *g*

Re: Best place to store a derived model and to make it referable from the DSL [message #1778173 is a reply to message #1778168]

Mon, 11 December 2017 08:27

Eclipse User

Maybe someone can give me a small example or step by step description how you would solve this.

Re: Best place to store a derived model and to make it referable from the DSL [message #1778179 is a reply to message #1778173]

Mon, 11 December 2017 08:48

Eclipse User

file a
defines A, derives Astar
file b
defines B, derives BStar, references AStar.

works out of the box

Re: Best place to store a derived model and to make it referable from the DSL [message #1778189 is a reply to message #1778179]

Mon, 11 December 2017 10:07

Eclipse User

Hi Christian,

it's really so simple ! One reason more to love Xtext :)

Thanks for your help guys !!!

Previous Topic:	Standalone code generation for list of files
Next Topic:	Can I modify a java file using XTend?

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 26 15:53:51 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter