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

[ https://issues.jboss.org/browse/DROOLS-3406?page=com.atlassian.jira.plugi... ] Roger Martínez edited comment on DROOLS-3406 at 12/19/18 9:52 PM: ------------------------------------------------------------------ Hey [~manstis] Yeah I see - well that's in fact "up to you"... :) I mean, when we built this initially we tried to split the presenter/handlers and the views, in case at some further point, we decide to change from lienzo to any other third party canvas library... that's something difficult to happen, but as in the rest of the platform, the idea is try to isolate the code, you know... So in Stunner some of the most used user related events, like click, drag, etc, are being provided by the API, and mostly all of the canvas controls are just relying on those. This doesn't mean we have to move all lienzo events to Stunner. In fact, probably in your case, it makes no sense to me as well, as it's all likely just domain specific stuff and should not affect third parties... So here up to you, but you can for example create a canvas control class, which does not really depends on lienzo, and create a view interface for it. The implementation for the view can be placed on any module that depends on lienzo, and as we use to do, keep a reference to the presenter. This way you can listen for the lienzo events on the view side, and just call the right callback methods on the presenter. Does that works for you? Anyway feel free to choose your approach considering there is no need to move lienzo events to stunner, for me np! Thanks! was (Author: roger600): Hey [~manstis] Yeah I see - well that's in fact "up to you"... :) I mean, when we built this initially we tried to split the presenter/handlers and the views, in case at some further point, we decide to change from lienzo to any other third party canvas library... that's something difficult to happen, but as in the rest of the platform, the idea is try to isolate the code, you know... So in Stunner some of the most used user related events, like click, drag, etc, are being provided by the API, and mostly all of the canvas controls are just relying on those. This doesn't mean we have to move all lienzo events to Stunner. In fact, probably in your case, it makes no sense to me as well, as it's likely domain specific stuff. So here up to you, but you can for example create a canvas control class, which does not really depends on lienzo, and create a view interface for it. The implementation for the view can be placed on any module that depends on lienzo, and as we use to do, keep a reference to the presenter. This way you can listen for the lienzo events on the view side, and just call the right callback methods on the presenter. Does that works for you? Anyway feel free to choose your approach considering there is no need to move lienzo events to stunner, for me np! Thanks! -- This message was sent by Atlassian Jira (v7.12.1#712002)