More SuperBrewer3000.coffee[notation] questions #85
-
|
In looking at the contents of SuperBrewer3000.coffeenotation I see tags that appear to point to entries in SuperBrewer3000.coffee (thus providing labels for the graphics). And through experimentation I find that these files are updated and kept in sync when changes are made in either the tree editor or diagram editor, and both of those editor views are kept synchronized. Of course, you knew that, but for me it was a discovery that answered a lot of questions. I'm guessing that all I/O to those two files happens within the model server. Is that true? Although I have cloned the model server to look at the source code I haven't found where that is done. If it is true, the implication is that the model server runs in a separate process so it can write to the file system, and this process has to be on the same machine as the client (in order to have access to the workspace where these files live). Right? I'd like to understand exactly what the model server holds in memory as a representation of the evolving instance model. As best as I can tell with my limited look at the model server's source code the instances are maintained internally in JSON format (I'm looking at classes Json and DefaultJsonSchemaConverter). Is that correct? Finally, it looks to me like the demo's tree editor is code that entirely runs in the browser, except for calls it makes to the model server. Correct? Although I'm not looking for a specific answer I'd like to make a related observation. I originally thought (hoped?) the 'tree editor' was some generic, magical piece of software that interpreted the meta-model and dynamically built the UI based on that. I was a bit shocked when I really looked at the tree editor code and found out there is no generic functionality (except for the Theia widget it uses) and instead the 'tree editor' has to be written from scratch for each meta-model. IOW, the coffee editor's tree editor code basically (and redundantly, in my view) re-specifies the complete coffee meta-model and what to do with it. Actually, I do have another question related to the need to write a tree editor pretty much from scratch. Let's say I don't need a tree editor. I think there might be a problem if I simply get rid of the existing tree editor code (coffee-editor-extension). This code is directly associated with the .coffee file. While the diagram editor appears to be centered on the the .coffeenotation file, it also, at least indirectly, makes use of the .coffee file. If the coffee-editor-extension code (tree editor) is gone but the diagram editor remains in place what happens to the management of the .coffee file? Thanks for your help! original thread by GaryKopp |
Beta Was this translation helpful? Give feedback.
Replies: 26 comments
-
|
Hi @GaryKopp(garykopp) , Some of your deductions are right, some are wrong ;-) . I also think it would be worthwhile to have a workshop with professional support to get you quickly on track. About your questions:
Best, |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] Thanks very much for the thorough explanation, Eugen. But it leaves me confused on one point. You say only the .coffee file is written by model server. Are you suggesting that the .coffeenotation file is not written by the model server? Doesn't that file have to be kept up-to-date as the GLSP diagram is updated? I thought this information would be persisted and survive the session. Is this one of my wrong deductions ? |
Beta Was this translation helpful? Give feedback.
-
|
Hi, |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] Ah, thanks Eugen. I was beginning to suspect GLSP was responsible for persisting the .notation file. I'm not really looking for an answer, but that situation makes me wonder how file integrity is managed. The .coffee and .coffeenotation files are tightly coupled (references in .coffeenotation to .coffee), but they're managed by two different processes at different points in time. Seems like that's asking for things to maybe get out of sync. |
Beta Was this translation helpful? Give feedback.
-
|
Yes and you are right, that managing resources that belong together by two different processes is an issue, this is why for the ecore-glsp example (https://github.com/eclipse-emfcloud/ecore-glsp) this is completely handled by the modelserver and for the glsp examples this is handled completely by glsp without the modelserver. |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] Thank you. That is very interesting and now I have to re-think things. I'm sort of starting from scratch but attempting to limit the amount of work involved by trying to adapt the coffee editor demo. It turns out that after my initial surgery to take out what I don't need, I end up with just the diagram editor (for now; I'll add more functionality later). That approach results in me inheriting the demo's warts like the questionable handling of .coffee and .coffeenotation. I want a model server since it will support my future functional additions. Would you agree that my best approach would be to abandon my work on adapting the coffee demo and base my implementation on the ecore-glsp example?? BTW, earlier you said 'Removing the tree but using glsp with the modelserver would still let the modelserver write the '.coffee' file'. That seemed to be specifically in reference to using the ecore-glsp example. Is that statement still true for the coffee editor demo itself -- will it correctly manage the .coffee file if all the tree-editor-extension is completely gone, or to ensure that would I have to use the ecore-glsp approach? I really appreciate your input! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @GaryKopp , Yes removing the tree won't change anything in the coffee editor. The coffee file will still be kept in sync by glsp calling the modelserver. Both the ecore-glsp as well as the coffee-editor are example applications. I would not base any custom application on any of those. I would always use them as an inspiration for your application. So maybe this very simple and incomplete example might help you understand the building blocks better. https://github.com/eclipsesource/uml-glsp It consists really just of Theia and GLSP.
For the modelserver it is important to understand and be able to create a model using EMF. |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] You're so damned helpful I don't know how to thank you adequately. Anyway, as you just mentioned, ecore-glsp contains the tree integration. I'm not configured right now for Docker, so I'm restricted to examining the ecore-glsp code, which I'm doing. Are there any screenshots of ecore-glsp in action? What I'm curious about is specifically the tree integration. Unlike the tree editor in the coffee demo, the ecore-glsp tree implementation is not specific to a given meta-model, and is generic. I suppose what it is displaying, and I'm still trying to figure this out from the code, is a hierarchical view of nodes in the current instance model, and also JSON Forms. Am I on the right track? And the JSON forms contain what? Do they perhaps support displaying and editing attributes associated with a model node? |
Beta Was this translation helpful? Give feedback.
-
|
The ecore-glsp example is not deployed and a blog describing it, is in progress. But you can use the docker image to start it locally to see it in action. The Tree story is complex and never completely generic as I mentioned before. For ecore-glsp the model is here https://github.com/eclipse-emfcloud/ecore-glsp/blob/master/client/packages/ecore-tree-editor/src/browser/tree/tree-model.ts So as a TL;DR; the tree renders the hierarchical structure of the data and jsonforms (this is a framework for creating forms) is used to display the data of each node in the detail view on the right. So yes JSONForms allows you to edit the attributes. |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] I'm back. I've built the ecore-glsp example and played with it a little. I'm wondering how well it would work with an arbitrary meta-model, like coffee's or the one I'm developing. Here's my concern, based on the example's UML workspace and UML.ecore. The meta-model carefully names a bunch of EClasses with meaningful names like 'Activity,' and these are reflected in the diagram, but the palette only shows basic EMF constructs (Classifier, Abstract, Class, etc.). I expected the palette in this UML sample to instead contain the elements found in the meta-model, like Activity, allowing me to add only model instances to the diagram that are valid in the underlying meta-model; I wanted to add an 'Activity' not a generic 'Class,' but I can't. Is that not the example's design goal? Actually, I think I just figured out what's going on. Correct me I'm wrong, but ecore-glsp is an example of a meta-model editor, not an instance model editor, right? Whereas the coffee editor is primarily concerned with editing instance models based on static meta-models (which is what I'm really trying to do). |
Beta Was this translation helpful? Give feedback.
-
|
Hi @GaryKopp(garykopp) , |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] Thanks again Eugen. Do you think ecore-glsp could be used as 'inspiration' for developing a solution for editing instances of a meta-model? From what I've seen so far, I doubt it, but then my understanding is still limited. On a related subject, do you have any idea on the status of updating the coffee editor demo? Is there a code branch under development that I have access to? I guess the real issue is that I'd like to scope out the details of what needs improvement/updating as I use it as an inspirational basis for my implementation. |
Beta Was this translation helpful? Give feedback.
-
|
Of course you can use ecore-glsp as a guide even if you want to modify instances. You will need a model anyway so the result is the same. |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] The potential problem with basing my solution of ecore-glsp is that, as it is currently coded, it updates the ecore file, which is a meta-model. I would have to change that and my code would have to use the ecore file simply as a static meta-model and introduce a new facility and file(s) to contain the instance data, which is what would be actually displayed and modified in GLSP. Sure, I can do that, but I'm thinking that's quite a bit of code. OTOH, that new code I'm talking about is already present in the coffee editor but it is specific to the coffee model, so I guess I'm still facing a major development effort. There's no free lunch, is there? |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] Will pull 371 include a partial rewrite of the .coffee and .coffeenotation files to consolidate their management in one process? |
Beta Was this translation helpful? Give feedback.
-
|
I think you are overthinking the problem. |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] I guess I'm being thick-headed, and just plain confused. OK, ecore-glsp is working with an instance of an ecore. The coffee editor, OTOH, is working with an instance that is represented as .coffee and .coffeenotation files, which to me are different than .ecore and .enotation files. In fact, the coffee editor also uses an ecore file, separate from the instance model, to provide metadata. Have I tried your patience to its breaking point, or can you try to straighten out my confusion? |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] I misspoke when I said the coffee editor also uses a .ecore file. Instead, it uses the Java class files created in EMF from the ecore file. And, as Philip pointed out to me, these are registered, as a package, with the Model Server. I don't see anything like that in ecore-glsp. |
Beta Was this translation helpful? Give feedback.
-
|
Your confusion is normal when people think of instance -> model -> meta-model -> meta-meta-model -> etc . As we use a custom model for the coffee editor we need to generate the java classes from the emf model. As ecore-glsp is using the default ecore model we can reuse the generated java classes from emf : |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] Thank you. That explanation is extremely clear and helpful, and actually seems to confirm what I was thinking. Maybe you can check my thinking. To base my development on ecore-glsp, but using a custom model along the lines of the coffee model, I need to introduce and register my meta-model's generated class files and create some very specific handling of that meta-model in place of ecore-glsp's coded-in handling of a vanilla EMF meta-model. IOW, the result would strongly resemble what is present in the coffee editor code. Do I seem to be getting close to understanding this? |
Beta Was this translation helpful? Give feedback.
-
|
yes that is exactly what you need to do! |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] Brilliant! Thank you, thank you, thank you for bearing with me through this process. Sorry for the delay in responding -- my Internet provider picked an inopportune time to go down. As further proof (or disproof) of my understanding, tell me if the following tracks, not that I am actually contemplating doing it. Instead of hard-coding (meta-)model references into implementation code as we have been discussing, it is at least theoretically possible to write a solution that interprets any (meta-)model (ecore), appropriately attributed, and generates code, either dynamically or in a separate step, that processes instances of that model in GLSP, etc. |
Beta Was this translation helpful? Give feedback.
-
|
[GaryKopp] One more question/clarification please. Looking at the ecore-glsp TypeScript source code it appears that it is not reactive. Whereas the coffee editor's frontend code does indeed seem to make use of the react library. Was not using a reactive style in ecore-glsp a conscious design decision based on something I would benefit from by knowing about? |
Beta Was this translation helpful? Give feedback.
-
|
Of course you could use EMF without generating code from the model, the question is why you want to do so? Please take a deeper look at EMF (https://www.eclipse.org/modeling/emf/) and some tutorials (https://eclipsesource.com/blogs/tutorials/emf-tutorial/). As long as you don't have a hard requirement to not generate code I would really recommend you to work on generated code. |
Beta Was this translation helpful? Give feedback.
Hi @GaryKopp(garykopp) ,
Some of your deductions are right, some are wrong ;-) . I also think it would be worthwhile to have a workshop with professional support to get you quickly on track.
About your questions:
only the '.coffee' file is written by the model server in the coffee editor example (you could handle both though)
yes the model server runs as a separate process and it needs to have access to the filesystem displayed by the workspace. As the idea is to deploy the whole application in a cloud your frontend would run in your browser whereas the backend would run in some image (maybe using kubernetes and thus even distributed over multiple volumes and images).
The model serv…