On Tue, Aug 16, 2016 at 11:06 AM, Viraj Rajaguru <[email protected]> wrote:
> Hi Kavith, > > Designing diagram view on top of a grid layout is a great idea. That will > reduce the overhead of calculating positions while automatic diagram > repositioning. And also it will lead to a more cleaner/organized visual > representation. > +1 for Snap to grid option, it will reduce the positioning and drawing issues for sure. > > And also it is good to use ANTLR Javasrcipt target[9] for > serialization/deserialization module as it will help us to use the same > ANTLR file for ESB runtime and tooling. > > Thought of sharing the few things regarding serialization/deserialization > module of older version of ESB graphical editor(See the attached pdf) which > might be useful designing serialization/deserialization module for NEL. > > Thanks, > Viraj. > > [9] - https://github.com/antlr/antlr4/blob/master/doc/javascript-target.md > > > On Tue, Aug 16, 2016 at 10:13 AM, Kavith Lokuhewage <[email protected]> > wrote: > >> Hi, >> >> Please note that the generated parser for NEL - link [7] - is moved to a >> different folder and it is now at >> https://github.com/wso2-incubator/js-tooling-framework/tree/ >> master/sequence-editor/js/nel-gen >> >> 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> >> >> On Tue, Aug 9, 2016 at 12:48 PM, Kavith Lokuhewage <[email protected]> >> wrote: >> >>> 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/se >>> quence-editor/ >>> [4] http://backbonejs.org/#Collection >>> [5] https://github.com/wso2-incubator/js-tooling-framework/b >>> lob/gh-pages/sequence-editor/js/app.js >>> [6] https://github.com/wso2/carbon-gateway-framework/blob/ma >>> ster/gateway-core/components/org.wso2.carbon.gateway.core/sr >>> c/main/antlr4/org/wso2/carbon/gateway/core/config/dsl/extern >>> al/wuml/generated/WUML.g4 >>> [7] https://github.com/wso2-incubator/js-tooling-framework/t >>> ree/master/sequence-editor/lib/nel >>> [8] https://github.com/wso2/carbon-gateway-framework/tree/ma >>> ster/gateway-core/components/org.wso2.carbon.gateway.core/sr >>> c/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 >> >> > > > -- > Viraj Rajaguru > Associate Technical Lead > WSO2 Inc. : http://wso2.com > > Mobile: +94 77 3683068 > > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Susinda Perera* Software Engineer B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL) Mobile:(+94)716049075 Blog: susinda.blogspot.com WSO2 Inc. http://wso2.com/ Tel : 94 11 214 5345 Fax :94 11 2145300
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
