Support Activiti Extension Elements

[dschulten]

Is your feature request related to a problem? Please describe. We make use of many activiti extension elements in our processes which are currently not editable (see below)

Describe the solution you'd like Make activiti extension elements accessible in ui, especially activiti:field for serviceTask , activiti:in and activiti.out for callActivity as well as activiti:formProperty for userTask.

Describe alternatives you've considered Editing extension elements in xml directly.

Additional context I think I have found the place where numerous extensionElements have been added with #36 (Activiti|FlowableParser.PropertyTypeDetails), but the ones I mention above are not among them. I could try to add them with some guidance. Assuming I add the new PropertyTypes and PropertyTypeDetails, what do I need to do to hook them up with editors?

TODOs:

• [x] Support for field nested element
• [x] Support for formProperty with nested elements
• [x] Fix issue with Property value within Form property binding
• [x] Handle creating new property and adding value
• [x] Handle id changes of properties (concurrent)

[valb3r]

@dschulten Those other extension elements were to be handled with #125. To support new properties:

I add the new PropertyTypes and PropertyTypeDetails

Yes, you are right - those are to be added there. All properties are visualized by PropertiesVisualizer so they should be picked automatically as they are broken into map. Theoretically thats' should be all needed for flat and simple properties.

But if not - then a mapper like UserTaskMappingshould be modified and maybe an extra mapper like ServiceTaskMapper<BpmnCamelTask> should be added depending on nestedness. The test to extend for example would be ActivityUserTaskTest.User task is parseable

Testing the plugin in development is quite easy - just import gradle project and click

[dschulten]

I am looking into it

[valb3r]

@dschulten If you provide an example BPMN file with all properties you need present I could implement this feature myself

[dschulten]

Turns out there is already some support for nested extension elements in ServiceTask, but if I am not mistaken, there is no UI to edit them. How should such a UI look like? Eclipse uses table views to represent activiti:field items (to define class fields on a Java Service Class). Would you like to do the same? I will commit sample process models in a feature branch on my fork and create a pull request for them, so you can have a look, too.

[dschulten]

PR https://github.com/valb3r/flowable-bpmn-intellij-plugin/pull/242 only has sample BPMN models. If you create an FBP-235 feature branch, I could point my PR to that feature branch.

[valb3r]

How should such a UI look like? Eclipse uses table views to represent activiti:field items (to define class fields on a Java Service Class). Would you like to do the same?

Yes, I would reuse already existing property table and expand it with buttons add/remove extension fields, like that. Form elements would be grouped in expandable tree-node alike control. My intent is to avoid having extra dialogs and do everything directly in Properties table

[dschulten]

What I am currently doing is to add the activiti:formProperty to UserTask following your example of the FieldExtensionElement in ServiceTask, so maybe I could integrate with the UI afterwards.

It would help me a lot if you could implement the UI for the already existing FieldExtensionElement as you envision it. Do I understand you correctly that you would like to add a button for extension elements to the property table UI which expands a tree-node control alongside a nested property table, where the tree contains the extension fields? If you highlight an extension field in the tree, such as field, the nested items of field would appear in the nested property table? (This is somewhat difficult to explain, therefore my request if you could help with the ui).

BTW the current master version does not build in Intellij (Gradle builds fine), some .form files claim that the binding class doesn't exist or is excluded from compilation. Also, in https://github.com/valb3r/flowable-bpmn-intellij-plugin/tree/master/xml-parser-api/src/main/kotlin/com/valb3r/bpmn/intellij/plugin/bpmn/api/bpmn/elements/subprocess there are two files having a name which only differs on a case-sensitive file system and causes problems otherwise - BpmnAdHocSubprocess.kt is empty while BpmnAdHocSubProcess.kt is not, maybe the former could be removed?

[valb3r]

Do I understand you correctly that you would like to add a button for extension elements to the property table UI which expands a tree-node control alongside a nested property table, where the tree contains the extension fields?

Yes something like that

If you highlight an extension field in the tree, such as field, the nested items of field would appear in the nested property table?

Rather when you click on parent element its children are shown, but yes

This is somewhat difficult to explain, therefore my request if you could help with the UI

I'll try to come with some initial implementation this week/weekend

BTW the current master version does not build in Intellij (Gradle builds fine), some .form files claim that the binding class doesn't exist or is excluded from compilation.

That's weird, I've tested on fresh Idea install it worked... Bumping org.jetbrains.intellij to the latest version may help

there are two files having a name which only differs on a case-sensitive file system and causes problems otherwise - BpmnAdHocSubprocess.kt is empty while BpmnAdHocSubProcess.kt is not, maybe the former could be removed?

Yes BpmnAdHocSubprocess.kt can be removed

[dschulten]

The update mechanism currently supports String and Boolean and you are using events to update them. How should an update of an extension element work for something like activiti:formProperty:

<activiti:formProperty id="fullProperty" name="Full Property" type="string" expression="${foo}" variable="fullProperty" default="aValue" datePattern="DD.MM.YYYY">
            <activiti:value id="value1" name="Foo"></activiti:value>
            <activiti:value id="value2" name="Bar"></activiti:value>
</activiti:formProperty>

or activiti:field:

<activiti:field name="recipient">
        <activiti:expression><![CDATA[userId:${accountId}]]></activiti:expression>
</activiti:field>
<activiti:field name="multiline">
        <activiti:string><![CDATA[This
                is
                multiline
                text]]>
        </activiti:string>
</activiti:field>

or modeler:activiti-idm-initiator:

<modeler:activiti-idm-initiator xmlns:modeler="http://activiti.com/modeler"><![CDATA[true]]></modeler:activiti-idm-initiator>

I have seen that you have started to support subtypes of BpmnExtensionElement such as BpmnOutExtensionElement. Should there be a common ExtensionElementUpdateWithId: EventPropagatableToXml which carries subtypes of BpmnExtensionElement? Or would you prefer separate events for each kind of extension element, sth like FormPropertyValueUpdatedEvent, FieldValueUpdatedEvent?

And should there be one PropertyType EXTENSION_ELEMENT or rather distinct property types for each kind of extension element?

[valb3r]

Unfortunately, I haven't worked with form fields much, so its more like rough guesses

The update mechanism currently supports String and Boolean and you are using events to update them. How should an update of an extension element work for something like activiti:formProperty

Form seem to require location by its ID, so custom events are necessary

• For formProperty itself - at first glance, looks like it is better to add custom event that extends PropertyUpdateWithId that carries formProperty.id to locate that property (i.e. FormPropertyUpdateWithId)
• For formProperty values - at first glance, looks like it is better to add custom event that extends PropertyUpdateWithId - i.e. FormPropertyValueUpdateWithId that carries both formProperty.id and formProperty.value.id to locate that property

Field does not seem to require location by its ID (they seem to be unique)

• For activiti:field - it looks like it is ordinary extension (as only one element can be defined) element with limited amount of data types, so for <activiti:field name="recipient"> FIELD_RECIPIENT(PropertyType.FIELD_RECIPIENT, "extensionElements.activiti:field?name=recipient.activiti:expression.text", XmlType.CDATA),
• For <activiti:field name="multiline"> - also looks ordinary (as only one element can be defined) FIELD_MULTILINE(PropertyType.FIELD_MULTILINE, "extensionElements.activiti:field?name=multiline.activiti:string.text", XmlType.CDATA),
• For modeler:activiti-idm-initiator - also looks ordinary (as only one element can be defined) MODELER_IDM_INITIATOR(PropertyType.MODELER_IDM_INITIATOR, "extensionElements.activiti:modeler?name=activiti-idm-initiator.http%3A//activiti.com/modeler:string.text", XmlType.CDATA),. The only thing it would checking if namespace http://activiti.com/modeler is not defined yet and if not adding xmlns:modeler="http://activiti.com/modeler" namespace

I have seen that you have started to support subtypes of BpmnExtensionElement such as BpmnOutExtensionElement. Should there be a common ExtensionElementUpdateWithId: EventPropagatableToXml which carries subtypes of BpmnExtensionElement? Or would you prefer separate events for each kind of extension element, sth like FormPropertyValueUpdatedEvent, FieldValueUpdatedEvent?

I would prefer separate events for each kind of extension element until it is clear that a lot of stuff is duplicated

And should there be one PropertyType EXTENSION_ELEMENT or rather distinct property types for each kind of extension element?

Distinct types with long name like FIELD_RECIPIENT looks better atm.

[valb3r]

@dschulten Initial PoC would take some more time, unfortunately, I do not have that much free time to spare atm.

[dschulten]

will try to come up with custom events, going slowly though

[valb3r]

@dschulten

BTW the current master version does not build in Intellij (Gradle builds fine), some .form files claim that the binding class doesn't exist or is excluded from compilation.

I've updated the build script and dependencies in master, so now the build should work cleanly

[valb3r]

@dschulten I've merged this feature to master, you can test this build of the plugin if you wish: activiti-bpmn-plugin.zip (to remove property or value simply type empty name)

[valb3r]

Rest elements are to be covered with https://github.com/valb3r/flowable-bpmn-intellij-plugin/issues/263