Modeler Template Capability - Custom field versus native field

Hi guys,

Im starting to make extensive use of modeler templates. I have noticed that I can do things such as include inline script, the script format etc. This is great! Hence sample template snippet may look like;

  {
    "label": "Script",
    "type": "Text",
    "value": "println Hello_World",
    "editable": false,
    "binding": {
      "type": "property",
      "name": "bpmn:script"
    }
  },
  {
    "label": "Script Format",
    "type": "String",
    "value": "groovy",
    "editable": false,
    "binding": {
      "type": "property",
      "name": "scriptFormat"
    }
  },

However, whilst this populates the script elements and attributes etc, on the properties panel, the fields are now doubled up. Hence the inline script will appear in the native script textbox, as well as a custom field text box.

Hence Id like to clarify - is the scope intent of templates the ability to include these attributes and elements such as inline script etc? Is this a known bug that the content will be doubled up in terms of displayed via the native property panel as well as the custom field panel?

regards

Rob

Hi Rob,

You are right, it would be a nice feature.
However you could handle that by disable it manually in the entriesVisible section:

 "entriesVisible": {
      "_all": true,
      "script-implementation": false,
      "scriptResultVariable": false,
    }

regards,
Dominik

Thanks Dominik,

Yes - I had considered using the visible toggle. However I guess what Im asking in a round about way is should templates have the ability to parameterise the native properties? If so, my preference would be not to have the hide the native property.

As I said, the functionality currently works, however given the above, Im not 100% sure if thats by design or chance…

regards

Rob

Hi Rob,

In my point of view the main idea of templates is to configure elements with little effort while modeling.
I want to provide as less properties as possible to the user. In that kind of domain specific lowcode I think the current way is sufficient so far. Or what is your opinion about that?

However I understand the use case of your idea and it would be a nice feature.
For example if I want to create some little preconfigured templates.
Therefore it would be great if they just parameterise the native properties.
However I often want to create properties that doesn’t exist (like the ones in the Mail Task example).
At this point it gets tricky and less clear to configure the templates or am I wrong?
Moreover if you take a look at the CustomProps I guess it would be hard work to implement that.
Maybe you can also open a discussion in the bpmn.io forum?

regards,
Dominik :slight_smile: