[jboss-jira] [JBoss JIRA] (DROOLS-3406) [DMN Designer] Decision Service splitter should be movable

Roger Martínez (Jira) issues at jboss.org
Sun Dec 9 21:41:00 EST 2018


    [ https://issues.jboss.org/browse/DROOLS-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13672456#comment-13672456 ] 

Roger Martínez commented on DROOLS-3406:
----------------------------------------

Hey [~manstis], here are some comments:
* If you recall correctly in Stunner we have "viewers", "editors", and other kind of "working modes" available. So they way this works is usually via "CanvasControl"'s, by enabling or disabling them for each case, or at least that's the way it was initially designed... hehe. So this is why I would recommend doing your work, if makes sense, by mixing code in some existing/new canvas control type and/or the shape view instance if self. This way, for example, you can just enable your control in case of edit mode, and keep it not available when just "vieweing" the diagram
* This way the idea is to add as much logic as possible in the CanvasControl rather than in the ShapeView itself, allowing this way to handle this new feature with the canvas control API. For example we use to handle all events and user interactions in the control classes, rather than on the shape views 
* Anyway I know that word is not ideal and sometimes it's necessary to add custom logic on top of the ShapeView, which is also usually built and generated automatically by the SVG annotation processor. This ability was also already necessary for the new Case Modeller editor, which is using SVG views and also provides custom logic on top of ShapeView. So you can do this, if applies for you, in the same way. The idea is:
** Create a custom _ShapeViewBuilder_ and use in your _SVGViewFactory_ declaration, by specifying it in the _builder_ field. Eg: [CaseManagementSVGViewFactory|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-stunner/kie-wb-common-stunner-sets/kie-wb-common-stunner-case-mgmt/kie-wb-common-stunner-case-mgmt-client/src/main/java/org/kie/workbench/common/stunner/cm/client/resources/CaseManagementSVGViewFactory.java#L25]
**  This way you can also create a custom ShapeView type, for example as the [CaseManagementShapeView|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-stunner/kie-wb-common-stunner-sets/kie-wb-common-stunner-case-mgmt/kie-wb-common-stunner-case-mgmt-client/src/main/java/org/kie/workbench/common/stunner/cm/client/shape/view/CaseManagementShapeView.java#L34], which is being built in your custom _ShapeViewBuilder_.
** By following this, you can then _cast_ the _ShapeView_, in your _CanvasHandler_ type or any of your custom components, from ShapeView to your concrete implementation. 

So hope this helps a bit. Feel tree to ask for whatever you need or if any Qs, np!!

Thanks!

> [DMN Designer] Decision Service splitter should be movable
> ----------------------------------------------------------
>
>                 Key: DROOLS-3406
>                 URL: https://issues.jboss.org/browse/DROOLS-3406
>             Project: Drools
>          Issue Type: Enhancement
>          Components: DMN Editor
>    Affects Versions: 7.15.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>            Priority: Major
>              Labels: drools-tools
>
> The _splitter_ within a Decision Service is static.
> It needs to be movable (vertically) maintaining it's alignment with the Decision Service bounds. At this point we need to either decide to add _result_ decision(s) and _encapsulated_ decisions to the Decision Service by Command (depending on where the node is dropped) or update the Marshaller to determine the type of decision based on its vertical positioning and location of the _splitter_.
> h2. Acceptance test
> Decision state is updated according to _splitter_ movement. Example if area of result decision expanded so some decision belongs there now, this decision should have state _rusult decision_



--
This message was sent by Atlassian Jira
(v7.12.1#712002)



More information about the jboss-jira mailing list