nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Activiti Designer - Dynamic Properties in Custom Task

robertkujawa

Hi

I'd like to bring up issue concerning dynamic properties in Custom Service Tasks. The idea is to fill property container from other source .
In general scenario:
- dropdown property items can be populated from database, some files, etc
- properites can changes theirs content in runtime
- adding/removing properties in runtime

I have some ideas how to add such features in code

Find more posts tagged with

Comments

trademak

Hi,

Okay, that sounds like a good addition. Would you like to contribute it?

Best regards,

tiesebarrell

Actually, we've thought about this before. The solution we came up with was to define an interface in Designer that would need to be implemented in an Eclipse extension by you as developer. You could then link the class to the custom service task by class name (we would have to provide an option for that). At runtime, Designer would simply instantiate the class that acts as a provider for the dropdown box and let it do its work to get the options.

What did you have in mind?

robertkujawa

I can propose some solution. I think I can develop such mechanism using Extension Point but first I have to better understanding some other mechanisms such a how properties are populated to UI, how their are manage, how we can refresh them etc

robertkujawa

tiesebarrell : I have in mind exactly the same scenario as you

robertkujawa

OK. After drunk few cups of coffee, revised source code I get into conclusions how this probably should be implemented (it's only a proposals)

1) According to my topic http://forums.activiti.org/en/viewtopic.php?f=8&t=2718 which I posted few days ago, I think we should extend this interface by adding some methods or properties which will be responsible for dynamic part of Custom Service Task. This approach will reduce and simplified code, since only one extension is involved and also reduce extra mapping between CST and dynamic properties (all in one class) in case if we have two EP (Extensions Point), one for CST and one for dynamic data.

2) Another question is how we can identify CST and populating dynamic data. I mean, if we have two identical CST and we want to change data only in one of them how we can recognize, since where aren't (maybe I'm wrong) special identification mechanism

If I omitted something and this is important, don't hesitate to mention this

tiesebarrell

Robert,

I'm not at work for the next couple of days, so it may be a while before I get back to you.

I agree that this would best fit an approach to CSTs where the CSTs are already defined in an extension, not in a regular JAR (there's no real easy way to maken the instantiation work and get to Eclipse stuff).

To identify CSTs, I believe we now use fully qualified class names and I would suggest we maintain it that way. I think the values should be looked up by instantiating the class and asking it for the possible values, but storage in the model can remain the way it is. We already have a similar option for comboboxes with statically defined values, so it should be simple to have a "Repository" implementation for CSTs 1 and 2 (so two extensions to the same extension point, two implementation classes) and ask each one of them if they can provide values for a CST of type <FullyQualifiedName>. If so, we take the values and create a combobox. If not, we move on to the next extension.

With regards to your second question, do you mean having two fields on 1 CST that need different data? In that case I think we need Field IDs, which we don't have at the moment. However, if we allow you to specify that ID string in the @PropertyItems annotation instead of static values, I think we could make a nice match with the existing functionality and get down to the field specific level

Does this make sense for your use case?

robertkujawa

tiesebarrell,

By identify CST I mean there are two equal CST on the canvas. For example:
First is called "Gate1" and second "Gate2" which only names are different, but body remains the same and same amount of properties inside.
So the question is: how I can recognized particular CST to populate data only to one them (i.e new combo items)?

tiesebarrell

robert, do you mean you would want to populate the combobox differently for one cst than for the other, using the same extension? so you need the context of the particular cst's id to be able to keep them apart? I never thought of that use case to be honest. At the moment that would be hard to do I suppose, although in principle we should be able to supply the id as context. I'm wondering how you would be able to use the id to determine what to do?

robertkujawa

It was only a Analytical Issue. Now I understood that this scenario is hard to implement and better way is to create 2 different CST

Since creating CST is not a big coding problem

pascal1

- dropdown property items can be populated from database, some files, etc
- properites can changes theirs content in runtime
- adding/removing properties in runtime

Hi,
I just have the same problem: I want to fill the PropertyItems of a COMBOBOX_Choice by an Array/List that depends on a config-file. But there is only the "static" way @PropertyItems({ ACCOUNT_TYPE_SAVINGS_LABEL, ACCOUNT_TYPE_SAVINGS_VALUE}) ?

Is something, discussed in this thread, implemented yet? An Interface or a possibility to change the PropertyItems?

Thanks for your help,
Pascal

tiesebarrell

There was only a discussion here. As far as I know, no definitive plan was drafted to implement these things. If you have ideas, please post them.

cortelos

Hi,

I'm really interested in the option of use a combobox which is populated from an external datasource (url, database or something like that).

In my opinion, it could be done in two ways:
1) as already suggested in this post, load the value list from a class (which should be referenced in the annotation). The class should be available in the classpath of the eclipse designer.

2) "transform" the combox in a text field with an help option where a new window would appear (when clicked) with a list (or tree) of data. The user could then select the data from the tree, and when the window in closed the selected values should be passed to the form. In the property annotation it would be necessary to indicate the source (java class) for the data.

I'm available to contribute for both of the options.

Regards,

André Macedo.

javaj3d1

Hey was this ever implemented?