A working implementation

[ankushbhardwxj]

I had referenced at our earlier discussion regarding the Concerto Web Editor issue, that I was building a prototype. So, I started playing around with Dan's idea and have made a simple prototype which I think is a great improvement towards the project. Pinging @irmerk @DianaLease @dselman @jeromesimeon to check this out. Please give suggestions and discuss further. Click https://relaxed-elion-1cd97b.netlify.com/ for a live demo.

Working

What's the progress ?

• Parsed concerto schema language code for concepts, properties and relations and differentiated them into two maps. Please check the console on the demo for that.
• Set up a "GO-JS" react graphical editor which can be used to create, edit, diagrams.
  • Double click to create new node. Press "delete" to remove node.
  • Relationship links can be altered
  • Concept names can be altered
• Set up a "Monaco" editor to write code.

What's left to do ?

Setting up part is done. We need to work on exchanging data between the two components.

• We need to feed the two maps to the model(JSON) on which the diagram is built.
• We need to take the JSON model from diagram and convert to code.
• Store diagram changes to state or use Redux

I shall begin with writing a GSOC proposal for this project once I get to know your feedback. Thanks !

[irmerk]

Referencing the issue with discussion for reference.

[irmerk]

I think this is a great approach. I'm really curious how we'll end up handling the arrow coming from the UML type diagram. It seems like this project is mostly focused on going from right to left in the diagram you made.

[ankushbhardwxj]

@irmerk That's a great question ! So, we have two arrays nodeDataArray (which contains info about a concept) and linkDataArray (which contains info about linking amongst different concepts), which would be in an Application State managed by Redux. In the L to R part, we parse the code "onChange" and make changes to the state arrays using an action called SEND_CODE_UPDATE. Similarly in the R to L part, we will have functions(see Elements.tsx in code) which will look for changes in the diagram and would make changes to state arrays using an action called SEND_DIAGRAM_UPDATE. Both the components will receive state using store.getState() and will be in sync to each other

Hope this explains the process. Also, to make things clearer consider playing around with my prototype at https://relaxed-elion-1cd97b.netlify.com/ I made changes while waiting for feedback.

[dselman]

This looks like a great start! Perhaps looking at some existing UML editor tools would provide visual and UX inspiration?

https://marketplace.eclipse.org/sites/default/files/UML%20Lab%20Screenshot%20Shop_2.png

Some comments:

1. You should use the Concerto parser to parse the CTO contents. Eg replace this code: https://github.com/ankingcodes/ConcertoWebEditor/blob/master/src/App.js#L128

With something like:

const ModelManager = require('@accordproject/concerto-core').ModelManager;
const modelManager = new ModelManager();
modelManager.addModelFile( concertoFileText, 'filename.cto');
const assets = modelManager.getAssetDeclarations();

ModelManager API: https://docs.accordproject.org/docs/concerto-api.html#module_concerto-core.ModelManager+getAssetDeclarations

This will give you an array of ClassDeclaration that you can work with: https://docs.accordproject.org/docs/concerto-api.html#module_concerto-core.ClassDeclaration

Note that Concerto ships with Typescript declarations, if you are using TS.

2. I would restructure your code to have a class that manages the model for the diagram - as this will be the pivot model that will gets updated when the CTO text is modified (via parsing it using the ModelManager above), and is modified when someone moves boxes, or adds arrows in the graphical editor. For example, the graphical model will track the location of the boxes and arrows. Making this a separate class (independent of React?) will make it easier to test.

3. You will need to write code that (re)generates CTO text from your diagram model. You will need to decide how/if the graphical layout information gets persisted into the CTO file. E.g. you could use Concerto decorators to persist additional graphical metadata:

@location( 200, 300 )
concept Test {
   o String name
}

Note that we generate text from the ModelManager using the Visitor Pattern. Here is the code that converts a ModelManager to a PlantUML file - we could implement something similar to dump a ModelManager back into a CTO file.

https://github.com/accordproject/concerto/blob/master/packages/concerto-tools/lib/codegen/fromcto/plantuml/plantumlvisitor.js

4. You will need some sort of palette or toolbar for the graphical editor to add new class declarations, add properties to an existing class, add relationships between classes etc.

[ankushbhardwxj]

@dselman Thanks for these detailed comments.

Perhaps looking at some existing UML editor tools would provide visual and UX inspiration?

This is just a rough mock that I'm preparing just to understand the project better. We would definitely work on improving UX after I'm done with the proposal.

You will need some sort of palette or toolbar for the graphical editor to add new class declarations, add properties to an existing class, add relationships between classes etc.

Actually Go-JS takes care of that for us. They have functions that can help with modifying the diagram. Currently, if you check on the demo link, you can double-click to create a new node, change the name of a node and it gets updated in state, make relationships between nodes and they rearrange themselves according to relation, delete nodes by pressing delete key,etc.

Let's clarify some things though, by iterating over the idea :

diagram --> code (more priority on this)

1. I will be using an application state (REDUX) for the model. (instead of the class, maybe) ( @dselman please advise if REDUX would be a bad choice ) ( going with Redux since most Go-js examples work out using the component state or an application state )
2. The modelManager would be stored in the state.
3. Any changes made to diagram would be used to update the model in the state.
4. Code editor uses Redux's getState() to get the model and then we write some code which converts the model to a CTO file.

   code --> diagram (less priority on this)

5. User writes some code which "onChange" is parsed using Concerto Parser
6. This model is used to update State.
7. Go-JS derives state using getState() and adjusts diagram accordingly, using its own set of functions.

If the idea seems okay, I'll do some more work on this. 👍

[DianaLease]

Hi @ankingcodes, this sounds great! Some quick feedback I have:

• If you feel the complexity of the application state warrants using Redux, then by all means, use it :)
• If you are familiar with React hooks, it would be great to use functional components throughout the app instead of class components (https://reactjs.org/docs/hooks-reference.html)
• As for Dan's suggestion around a toolbar, I think you could map those existing GoJS methods you mentioned for editing the diagram to a toolbar to make them more accessible.

[ankushbhardwxj]

Thanks @DianaLease !

If you are familiar with React hooks,

Great that you mentioned this. That said, this is just a mockup. I wrote the code in a really messy way here just to make sure things work as I want. The purpose being, understanding the intricacies of the project. I'll definitely write really clean code and follow all Accord Project coding practices once I get my proposal ready.

As for Dan's suggestion around a toolbar, I think you could map those existing GoJS methods

Surely, that can be done. Alternatively we can add some instructions to create diagrams. However, that's an UX issue and we can adapt to what seems best. 👍

Also, since Gsoc applications open 16 March, is there any specific proposal template for Accord Project? I'd make a draft proposal early enough so that I could get feedback from mentors.

[irmerk]

This all looks really good @ankingcodes, very promising!

Also, since Gsoc applications open 16 March, is there any specific proposal template for Accord Project? I'd make a draft proposal early enough so that I could get feedback from mentors.

Not super defined, but follow what we mention in the "How to work with us" section here:

• Project Info
  • Detailed description
  • Deliverables
  • Related work
  • Benefits
  • A timeline
• Personal Info
  • Contact and biographical
  • Previous projects (if any)

[ankushbhardwxj]

In my last commit, I have used Concerto Parser and used the ModelManager API to update the diagram as code changes. Then when I started to work on relationships between the nodes, I quickly understood why Dan suggested the following :

I would restructure your code to have a class that manages the model for the diagram - as this will be the pivot model that will gets updated when the CTO text is modified (via parsing it using the ModelManager above), and is modified when someone moves boxes, or adds arrows in the graphical editor. For example, the graphical model will track the location of the boxes and arrows. Making this a separate class (independent of React?) will make it easier to test.

I am unclear about how I could implement this. Especially the independent of React part. All go-js diagram modifications are supposed to update the state (of the form of object/array). I'd love to hear some suggestions on how we should implement this in a state or rather a React independent class. If we have a class how would that be integrated with React?

[ankushbhardwxj]

const ModelManager = require('@accordproject/concerto-core').ModelManager; const modelManager = new ModelManager();

@dselman This works fine locally but I got error TypeError: Cannot call a class as a function when I deployed my branch to the given link.

[ankushbhardwxj]

I worked around on the pivot model using Model Manager. Now it looks as follows on my local.

Editing code works fine. I went through Go-js some more. They have readymade methods for a pallete (drag and drop allowed) , a class data viewer which can be easily integrated to the diagram.