Hi, As part of Next Gen Tooling based on web platform, we are currently working on an interactive visual editor for next generation ESB language (NEL).
You can find the initial work at [2 <https://wso2-incubator.github.io/js-tooling-framework/sequence-editor/>][3 <https://github.com/wso2-incubator/js-tooling-framework/tree/master/sequence-editor>]. Please note that this is still at a very basic stage. This mail is to summarize the path that we are going forward on. *Initial implementation of diagramming module* Diagramming module provides a canvas with drawing capabilities and means for binding data objects to each visual element drawn. With regards to framework stack, currently we are using BackboneJS <http://backbonejs.org/>, Lodash <https://lodash.com/> and D3 <https://d3js.org/> as the base for diagramming module. We are using BackboneJS to structure the code with model-view separation and to utilize OO implementation provided by it. Furthermore, we use BackboneJS collections <http://backbonejs.org/#Collection> [4] to group similar models. Upon various events which are triggered by the model, BackboneJS views are capable of rendering/manipulating visual elements related a particular model. BackboneJS Collections provides a set of methods to deal with events on a collection of similar models. Currently we are using D3, only to manipulate SVG. We are not utilizing any data driven features of D3. Lodash is an utility library - a more stable and performing variant of underscore - on which BackboneJS depends on and we also use for utility functions. Below diagram shows the basic structure of models in the diagramming module. Relevant views for each model, also follows a similar structure. Note that this only describes the models for diagramming module of NEL editor. For example, with regards to NEL serialization/deserialization module, there will be a separate object model to represent Abstract Syntax Tree (AST) of NEL. Each model can trigger a set of events upon various scenarios. For example, when a new element is added to the diagram, Diagram model triggers an event called "onElementAdded". DiagramView listens to this event and fetches the newly added element. Then it will initialize relevant view - while passing provided options for view (if any) - and call render method of that child view. For another example, when a shape is moved, it will trigger a move event, to which all connection points of that shape will listen. Connection Points will delegate the event to connected links either as "sourceMoved" or "destinationMoved". View for Links is capable of redrawing the link upon these events. In future, we are thinking of using events with collections to handle more advanced use cases. For example, a diagram has a collection of elements. When a user starts to draw a link from a source connection point, link can fire an event indicating that it is searching for possible destinations. Diagram can listen and delegate that event to its collection of elements. Upon the delegated event, each element will notify it's connection points about this possible incoming connection. Views of the connection points - which are qualified to be the destination for this particular link - can then indicate so by giving a visual clue such as change of color, etc and act as a magnet. BackboneJS with Lodash provides an optimized and well established framework to implement above mentioned scenarios. Please have a look at the code snippet <https://github.com/wso2-incubator/js-tooling-framework/blob/gh-pages/sequence-editor/js/app.js> [5 <https://github.com/wso2-incubator/js-tooling-framework/blob/gh-pages/sequence-editor/js/app.js>] which draws [2 <https://wso2-incubator.github.io/js-tooling-framework/sequence-editor/>], to get an idea of diagramming module. *Avoiding the requirement for persisting graphical data* During the initial reviews, it was identified that allowing users to drag/move elements freely on the canvas, will cause a lot of issues while regenerating a particular diagram identically on a new workspace/or on editor restart. Even-though persisting graphical positioning data may resolve most of the issues, since NEL model does not allow keeping those data within NEL and keeping a separate file for graphical data is not an option, it was decided that we should put more restrictions on drawing capabilities allowed for users. However, while keeping those restrictions, we need to make sure that users get enough interactive features they need such as drag-drop, reorder, etc. Considering above, we are looking through a grid based approach as described below and hoping to start implementing it. Please share your thoughts too. All the elements in diagram will always stick to a vertical or horizontal (or both) line in a grid. This gird can just be a virtual grid where only the coordinates of lines will be kept within DiagramView. Cell size will be adjustable. Location of a particular element within the grid will be calculated with the help of location of the data node within the AST of NEL. When dragging-dropping from toolbar,moving or reordering, elements will always snap to the closest grid lines. Nodes in AST will be created, moved or swapped according to grid position of the elements involved. This is just an high level description on the solution. However, we may need to revisit some of these when going forward with the implementation. *NEL serialization/deserialization module* Using the ANTLR grammar file <https://github.com/wso2/carbon-gateway-framework/blob/master/gateway-core/components/org.wso2.carbon.gateway.core/src/main/antlr4/org/wso2/carbon/gateway/core/config/dsl/external/wuml/generated/WUML.g4> [6] for NEL, a Javascript parser is generated [7] to parse NEL. Using this parser, it is possible to build an AST for NEL with a Javascript data model defined similar to the run-time data model for NE <https://github.com/wso2/carbon-gateway-framework/tree/master/gateway-core/components/org.wso2.carbon.gateway.core/src/main/java/org/wso2/carbon/gateway/core/flow>L[8] defined in java. Diagramming module and this module will work together to generate NEL from diagram and vise versa. *Remaining things to initiate* Testing, package management, build, etc. are a few aspects which are next in line to be started. To get an idea about overall effort on next gen tooling, please refer to [1]. [1] [Architecture] A JavaScript based Tooling Platform for WSO2 Middleware [2] https://github.com/wso2-incubator/js-tooling-framework/t ree/master/sequence-editor [3] https://wso2-incubator.github.io/js-tooling-framework/sequence-editor/ [4] http://backbonejs.org/#Collection [5] https://github.com/wso2-incubator/js-tooling-framework/ blob/gh-pages/sequence-editor/js/app.js [6] https://github.com/wso2/carbon-gateway-framework/blob/master/gateway-core/components/org.wso2.carbon.gateway.core/src/main/antlr4/org/wso2/carbon/gateway/core/config/dsl/external/wuml/generated/WUML.g4 [7] https://github.com/wso2-incubator/js-tooling-framework/tree/master/sequence-editor/lib/nel [8] https://github.com/wso2/carbon-gateway-framework/tree/master/gateway-core/components/org.wso2.carbon.gateway.core/src/main/java/org/wso2/carbon/gateway/core/flow Thanks, *Kavith Lokuhewage* Senior Software Engineer WSO2 Inc. - http://wso2.com lean . enterprise . middleware Mobile - +94779145123 Linkedin <http://www.linkedin.com/pub/kavith-lokuhewage/49/473/419> Twitter <https://twitter.com/KavithThiranga>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
