Issue with dropdown field

@marcoc Hi, I would like to share my opinion as follows:

Until and unless the components aren't read only, I would prefer to populating ACP in form inputs over saving the values to local variables and then rule inputs. If we carefully go through both the implementations, following observations can be made in the later(in which we make use of local variables):

1. There isn't a need to create local variables when we already have activity class parameters. In my view, when we already have a activity class parameter to populate the values, there isn't a need to additionally create the local variables and populate them. Loading the load() with unnecessary coding like this isn't appreciated. We need to bear in mind that activity class parameters already occupies some space (as per my knowledge) and it would be good if we don't additionally try to create burden on the interface by creating some additional variables and loading them with some values which again might require some time as well and also we need to code under a button. The approach won't seem good if we always create x (let's say x = 10) number of local variables for x number of inputs, populate x number of local variables in load() and further populate the x number of rule inputs from values of local variables finally when the form is submitted. Though load() undergoes execution once, it's better to keep it as simple as possible and away from unnecessary calculations.

2. If we create local variable for each rule input, the effort required while removing the rule input (and its associated logic) increases. Because creation and population of local variables in load() and copying the values of local variables into rule inputs under a button component is an additional activity as per my knowledge.

3. When we use local variable for saving values to rule inputs, in-case of components that has default values, and for other components if we just use rule inputs, this slightly leads to confusion. These kind of things require documentation or comments in the interface stating that components with default values makes use of local variable in any calculations or derivations as long as the form isn't submitted.

4. OOTB 'Save Changes' feature won't work in case of local variables and this isn't a great experience.


It would be good to opt for local variables approach only on need basis. For instance let's say there are some instances of process model that has a user input task and are active. Also let's assume that we should be providing a default value to a component. To accomplish the activity, rather than going for complex IFM operations such as restarting the previous task instances, it's quicker to add the local variable approach.

@marcoc Hi, I would like to share my opinion as follows:

Until and unless the components aren't read only, I would prefer to populating ACP in form inputs over saving the values to local variables and then rule inputs. If we carefully go through both the implementations, following observations can be made in the later(in which we make use of local variables):

1. There isn't a need to create local variables when we already have activity class parameters. In my view, when we already have a activity class parameter to populate the values, there isn't a need to additionally create the local variables and populate them. Loading the load() with unnecessary coding like this isn't appreciated. We need to bear in mind that activity class parameters already occupies some space (as per my knowledge) and it would be good if we don't additionally try to create burden on the interface by creating some additional variables and loading them with some values which again might require some time as well and also we need to code under a button. The approach won't seem good if we always create x (let's say x = 10) number of local variables for x number of inputs, populate x number of local variables in load() and further populate the x number of rule inputs from values of local variables finally when the form is submitted. Though load() undergoes execution once, it's better to keep it as simple as possible and away from unnecessary calculations.

2. If we create local variable for each rule input, the effort required while removing the rule input (and its associated logic) increases. Because creation and population of local variables in load() and copying the values of local variables into rule inputs under a button component is an additional activity as per my knowledge.

3. When we use local variable for saving values to rule inputs, in-case of components that has default values, and for other components if we just use rule inputs, this slightly leads to confusion. These kind of things require documentation or comments in the interface stating that components with default values makes use of local variable in any calculations or derivations as long as the form isn't submitted.

4. OOTB 'Save Changes' feature won't work in case of local variables and this isn't a great experience.


It would be good to opt for local variables approach only on need basis. For instance let's say there are some instances of process model that has a user input task and are active. Also let's assume that we should be providing a default value to a component. To accomplish the activity, rather than going for complex IFM operations such as restarting the previous task instances, it's quicker to add the local variable approach.