Hi Kavith, A great explanation on $subject! On high level I think we have to work on following now:
1. Implement the NEL parser and generate the visual representations of integration flows using NEL definitions. 2. Provide a toolbox and implement features to let the user visually draw diagrams. I think point 1 can be divided into two tasks: - 1.1 Implement a feature to render sequence diagrams based on a JS data model - 1.2 Implement the NEL parser and generate the above JS model Since the NEL grammar V1 is still not completed, I think it would be better to proceed with 2 now. WDYT? Thanks On Tue, Aug 16, 2016 at 11:12 AM, Susinda Perera <[email protected]> wrote: > > > 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 > > -- *Imesh Gunaratne* Software Architect WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: https://medium.com/@imesh TW: @imesh lean. enterprise. middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
