Hi Frank, On Sun, Sep 4, 2016 at 4:06 PM, Frank Leymann <[email protected]> wrote:
> Hi Imesh, > > please allow for a question: if I draw a diagram, I control the layout if > it and as long as I don't store it I can chance the size of the elements > etc - is that correct? But once I filed it, I can no longer change the > sizes and I can't change the position of the elements? Why not, i.e. what > is the technical problem behind it? > What we thought at the initial design meeting was, not to allow the user to position and re-size elements. Anyway I agree that it's a vital requirement of a diagramming tool. Let's discuss and see how we can support this. > > I just tried in Camunda editor: I can change everything and save, open > and change everything and save, open..... and the changes are all > preserved as I made them. Same is true for Signavio editor (tested just a > minute ago too). > > What the tools are doing is, that the corresponding .bpmn filel has two > subdocuments: one subdocument contains all the model elements to represent > the process MODEL (in the <process> element), and then the rendering > information for each model element including x-y-coordinates, height, width > etc (in the <BPMNDiagram> element). > > Thus, it state of the art to preserve the layouting information. I.e. we > shouldn't be weaker than the state of the art. Finally, you don't need to > introduce a second file but can maintain the layouting info in the same > file - but cleanly separate between the logic of the process model and its > layout info. > Thanks for pointing this out! I think this would work very well for diagrams which users would always use the tool to define the workflow. However for diagrams which users would prefer to directly write the language syntax, storing metadata on the same file may cause redability issues. How do you like the approach MySQL Workbench has taken for storing EER diagrams? Those diagram files store both the language definition and diagram metadata. When needed language definition can be generated from the diagram file. If the database structure is first created, the diagram file can be auto generated. Thanks > > > Best regards, > Frank > > 2016-09-04 4:31 GMT+02:00 Imesh Gunaratne <[email protected]>: > >> Hi Frank, >> >> On Sat, Sep 3, 2016 at 8:35 PM, Frank Leymann <[email protected]> wrote: >> >>> Let me even emphasize what Chathura wrote: users will be really annoyed >>> if we don't preserve the layout/rendering of a diagram. It will be a >>> show-stopper for using the tool.... >>> >> >> Thanks for your feedback! According to the current approach the layout >> and rendering of the diagram will be preserved. The tool will render >> diagrams the same way as the author drew it, for any other user. The only >> limitation user will experience is that, re-positioning and re-sizing of >> the elements will not be possible, those will be controlled by the tool. >> >> If we were to persist positioning and sizing information, we might need >> to introduce a diagram file inaddition to the language file. Do you think >> we need to follow that model? >> >> Thanks >> >>> >>> >>> Best regards, >>> Frank >>> >>> 2016-08-31 6:01 GMT+02:00 Chathura Ekanayake <[email protected]>: >>> >>>> Hi Susinda / Imesh, >>>> >>>> If positioning information is not stored with the diagram, does it auto >>>> adjust size and positioning of elements based on the length of text >>>> provided as lifeline labels and text on lines connecting lifelines? >>>> Further, are we allowing users to change the order of lifelines? >>>> >>>> I think, although we might not need for sequence diagrams, in general >>>> it may be better to store positioning information with diagrams as auto >>>> layouting can be a complex problem. In addition, users may feel lack of >>>> control over the diagram, if they cannot position elements. For example, >>>> BPMN stores positioning information for each task and sequence in a >>>> separate xml section, which is referred by the corresponding logical >>>> construct when drawing the diagram in a canvas. >>>> >>>> Regards, >>>> Chathura >>>> >>>> On Tue, Aug 30, 2016 at 4:24 PM, Susinda Perera <[email protected]> >>>> wrote: >>>> >>>>> Hi Imesh >>>>> >>>>> +1 for all other suggestions and comments >>>>> Multiple groups added only to demonstrate the tool-palette features, >>>>> not needed for this editor but may be useful for datamapper editor. >>>>> We need to finalize the icons for the various tools/actions - Hope ESb >>>>> team can give some input >>>>> We will have UX review fix the other UI issues, +1 for go with a theme >>>>> approach (like dark/white) >>>>> I'll do the code refactoring for the name changes and positioning >>>>> issues. >>>>> >>>>> Thanks >>>>> Susinda >>>>> >>>>> >>>>> On Tue, Aug 30, 2016 at 3:35 PM, Imesh Gunaratne <[email protected]> >>>>> wrote: >>>>> >>>>>> Great work Susinda! Few comments below: >>>>>> >>>>>> - I think initially we may not need multiple groups inside the >>>>>> tool palette for sequence diagramming module. >>>>>> - Maybe we can directly use the exact tool palette elements we >>>>>> need; Lifecycles, Mediators, and Arrows. >>>>>> - The term Tool used at Tools.Models.Tool, might not suit well. >>>>>> Shall we call it an Element/Item (a tool palette element/item)? >>>>>> - The images used inside the tool palette may need to have >>>>>> transparent backgrounds. >>>>>> - Overall, we may also need to consider following: >>>>>> - As we do not store positioning data, we may need to do the >>>>>> positioning for the user. If so we may not need to provide user to >>>>>> change >>>>>> the positioning of elements as needed. >>>>>> - We might need to update the colours of the elements and the >>>>>> tool palette according to a colour scheme. >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> On Tue, Aug 30, 2016 at 1:04 PM, Susinda Perera <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> The same webpage can be seen at here[1] >>>>>>> [1] - https://wso2-incubator.github.io/js-tooling-framework/sequen >>>>>>> ce-editor/index.html >>>>>>> >>>>>>> Thanks >>>>>>> Susinda >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 30, 2016 at 11:34 AM, Susinda Perera <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi All >>>>>>>> >>>>>>>> I have started implementing $subject. Figure[1] below is the >>>>>>>> screenshot of the current implementation. >>>>>>>> The implementation pf Tool palette is devided to following models >>>>>>>> and views (considering extendability) and the js code[2] describes the >>>>>>>> connectivity of the modules. >>>>>>>> >>>>>>>> ToolPalette / ToolPaletteView >>>>>>>> --ToolGroupWraper / ToolGroupWraperView >>>>>>>> --ToolGroup / ToolgroupView >>>>>>>> --Tool / ToolView >>>>>>>> >>>>>>>> TODO >>>>>>>> - Implement the drag and drop support >>>>>>>> - Implement the collapse of tool palette >>>>>>>> - Externalize the templates for toolView, toolgroupWrapperView and >>>>>>>> toolPaletteView >>>>>>>> >>>>>>>> Please give your inputs >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [2] -js code >>>>>>>> //create tools >>>>>>>> var calcTool = new Tools.Models.Tool({ >>>>>>>> toolId: "tool1", >>>>>>>> toolImage:"images/icon1.png" >>>>>>>> }); >>>>>>>> >>>>>>>> var calcTool2 = new Tools.Models.Tool({ >>>>>>>> toolId: "tool2", >>>>>>>> toolImage:"images/icon1.png" >>>>>>>> }); >>>>>>>> >>>>>>>> //create tool group >>>>>>>> var group = new Tools.Models.ToolGroup(); >>>>>>>> group.add(calcTool); >>>>>>>> group.add(calcTool2); >>>>>>>> >>>>>>>> //create tool palette >>>>>>>> var toolPalette = new Tools.Models.ToolPalatte(); >>>>>>>> var toolGroupWrapper = new >>>>>>>> Tools.Models.ToolGroupWrapper({toolGroupName: >>>>>>>> "LifeLines", toolGroup:group}); >>>>>>>> toolPalette.add(toolGroupWrapper); >>>>>>>> >>>>>>>> //render the palate View >>>>>>>> var paletteView = new Tools.Views.ToolPalatteView({c >>>>>>>> ollection:toolPalatte}); >>>>>>>> paletteView.render(); >>>>>>>> >>>>>>>> [1] - screenshot >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *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 >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> > -- *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
