| Sprotty for Mining and Analysis Workflow Visualization [message #1802949] |
Tue, 19 February 2019 13:37  |
 Patrick Neubauer
Messages: 4
Registered: May 2017 |
Junior Member |
|
|
Dear Sprotty developers,
We are members of the CROSSMINER EU project, which involves mining of open-source software from various providers, and developed Crossflow, i.e. a language to specify mining and analysis workflows [1].
As part of our web application, we would like to graphically visualise the workflow execution during runtime and found Sprotty to be a fitting candidate.
As a result, we generated an Xtext-based language of Crossflow, i.e. our workflow language, replaced the exemplary "multicore" language with it, and drafted the diagram generator accordingly.
Although we were able to produce a graph with nodes as well as compute its layout [2], we were unable to successfully visualise the result in the browser [3].
The experiment is available on Github [4] and is fairly easy to reproduce.
Can you provide any hint on what may go wrong?
Cheers, Patrick
[1] Crossflow metamodel: https://github.com/crossminer/scava/blob/crossflow/crossflow/org.eclipse.scava.crossflow.language/model/crossflow.pdf
Exemplary Crossflow workflow graph: https://github.com/patrickneubauer/sprotty-experiment/raw/master/img/img5.png
[2] Console output: https://github.com/patrickneubauer/sprotty-experiment/raw/master/img/img3.png
[3] Browser output: https://github.com/patrickneubauer/sprotty-experiment/raw/master/img/img2.png
[4] Experimental repo: https://github.com/patrickneubauer/sprotty-experiment
|
|
|
|
| Re: Sprotty for Mining and Analysis Workflow Visualization [message #1803436 is a reply to message #1802984] |
Thu, 28 February 2019 16:48  |
Patrick Neubauer
Messages: 4
Registered: May 2017 |
Junior Member |
|
|
Hi,
thank you very much for your reply!
The repos you mentioned helped us greatly in getting the example running in our web app (after minor changes like adapting the web socket port to 9090 from 8080, i.e. already used by our web app) [1].
Now we are wondering what we can *exclude* for our use case, which intends only the visualisation of a model (at least for the foreseeable future). In other words, no change in the structure of the model is required at runtime.
In general, we intend to specify either an ETL model transformation or a EGL code generation, which we are familiar with, to yield elk graph models from our Ecore models and feed the result to the elkgraph-web language server in order to get the layout for the client.
Two questions in this regard:
1. what part of the client code can be excluded?
2. the server code is still required to generate/refresh the model layout during runtime in case the user changes the browser window size and the like, correct?
If you could point out the right places where to look at, that would already be of great help!
Thanks and all the best,
Patrick
[1] our web app code is in the project org.eclipse.scava.crossflow.web in branch 'crossflow' ( https://github.com/crossminer/scava/tree/crossflow/crossflow ); the server-side code of your example is placed in the project org.eclipse.scava.crossflow.elkgraph
[Updated on: Thu, 28 February 2019 16:55] Report message to a moderator |
|
|
| Re: Sprotty for Mining and Analysis Workflow Visualization [message #1803469 is a reply to message #1803436] |
Fri, 01 March 2019 09:45 |
|
Patrick Neubauer wrote on Thu, 28 February 2019 17:48Two questions in this regard:
1. what part of the client code can be excluded?
2. the server code is still required to generate/refresh the model layout during runtime in case the user changes the browser window size and the like, correct?
1. I don't understand the question. What would you like to exclude?
2. In our Xtext examples the server is responsible for providing the model ("model source") and to compute layouts. In case the model is provided elsewhere, you can use elkjs to compute the layout in the client, so the server is not really necessary (see also elkgraph-web example with json). But if the source of your models is Xtext / EMF you'll need a server component anyway.
|
|
|
Powered by
FUDForum. Page generated in 0.02848 seconds
] 
Search
Help
Register
Login
Home
