-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: change task type when element template is applied #648
Conversation
/cc @nikku |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From quick testing I can say it works 👏
Implementation wise we should consider some things before we merge it. 👍
test/spec/provider/cloud-element-templates/cmd/ChangeElementTemplateHandler.spec.js
Outdated
Show resolved
Hide resolved
test/spec/provider/element-templates/cmd/ChangeElementTemplateHandler.spec.js
Outdated
Show resolved
Hide resolved
test/spec/provider/element-templates/cmd/ChangeElementTemplateHandler.spec.js
Outdated
Show resolved
Hide resolved
test/spec/provider/element-templates/cmd/ChangeElementTemplateHandler.spec.js
Outdated
Show resolved
Hide resolved
test/spec/provider/cloud-element-templates/cmd/ChangeElementTemplateHandler.spec.js
Show resolved
Hide resolved
@marstamm I could only have a quick look on this today. If a detailed look is needed from my end I can see what I can do tomorrow or on Monday. |
test/spec/provider/cloud-element-templates/cmd/ChangeElementTemplateHandler.spec.js
Outdated
Show resolved
Hide resolved
@nikku , I will tackle the "return new element" topic tomorrow, so nothing urgent. @pinussilvestrus already gave some great suggestions on the code, but would be great to get some feedback if it is the correct behavior for connectors as well. |
test/spec/provider/cloud-element-templates/cmd/ChangeElementTemplateHandler.spec.js
Outdated
Show resolved
Hide resolved
test/spec/provider/element-templates/cmd/ChangeElementTemplateHandler.spec.js
Outdated
Show resolved
Hide resolved
Added a few more comments, especially around the change command. TLDR: Let us work with the newly introduced |
Will test drive this against connectors as soon as I can. |
I added the requested changes in separate commits to help with reviewing the changes. I will squash them before merging. Ready for another round of reviews 🏇 (Please wait for Nico to confirm the behavior in Connectors land before approving) |
test/spec/provider/element-templates/cmd/ChangeElementTemplateHandler.spec.js
Show resolved
Hide resolved
5434384
to
1577ab4
Compare
Added last review hints and squashed all commits |
From what I found during initial testing, this works like a charm! We are aware of bpmn-io/bpmn-js-connectors-extension#32 as a limitation, but I guess our users will verify how crucial of a limitation that is, post April 12th 😉. |
I found one bug, not related to this PR, but to the overall "check if properties are still valid during replace" interaction:
I believe this is due to our C7 legacy of "only touching what has been defined"; it does not seem to be the appropriate behavior for C8 anymore. Created a bug for this (#653). |
templates.addAll(templateDescriptor); | ||
|
||
// then | ||
expect(errors(templates)).to.contain('template(id: <example.com.TaskToGateway>, name: <Element Type (Task -> Gateway)>): can not morph <bpmn:ServiceTask> into <bpmn:ExclusiveGateway>'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reason for this limitations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to prevent the changing to broken types, like Task -> Process
or Task -> SequenceFlow
. As the simplest approach, we decided to only allow Task -> Task
, Gateway -> Gateway
and Event -> Event
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, one way to approach this would also be "allow users to do what they want" (and see how the editing experience blows up in the process) :).
But I see how we rather want to be safe.
If we got that route though, why do we choose bpmn:Task
and not bpmn:Activity
as the base for all "task nodes".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we choose
bpmn:Task
and notbpmn:Activity
Good point, I see no reason for it. I'll change it 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code-wise I have two concerns (but just comments at this point):
Is the direct bpmn-moddle
dependency really required? What do we achieve with it (in terms of features / safeguarding our users) that we don't achive by other means?
What is, in two simple lines our rules for "appliesTo" / "elementType" validation?
I'm missing a bunch of comments (examples) in the test suite / source code which makes our logic there hard to follow.
We validate that:
We need it to check the above Assumptions. E.g.,
is valid, but requires the meta-model to validate that the Service Task is a subClass of |
Cf. #648 (comment). Maybe we can re-use the existing moddle instance? |
1577ab4
to
628a98a
Compare
export default function validate(descriptors) { | ||
return new Validator().addAll(descriptors).getErrors(); | ||
export default function validate(descriptors, moddle) { | ||
return new Validator(moddle).addAll(descriptors).getErrors(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really happy with this one, but we can't move the validation to ElementTemplates
because that would cause a circular dependency in the TemplateFactory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thing we're fine with this.
Moddle is the meta-model we rely on. If we start to validate type hierarchies (which you decided to do) there is no other way to add this.
628a98a
to
b378bd2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added 7eb303b on top. Looks good to me.
Try it out with
This PR allows you to define a
elementType
that will be enforced when a template is appliedcloses #572
closes #642