Big feature here : parameter values would be fed by a query. Where you see the paste button today to put values, there would also be a button “query”. It would open the query editor.
I think there would be 3 main restrictions for parameters:
You only select one field
You cant use the same parameter in the query or it would be infinite loop
You would have to restrict to 1000 first rows as parameters can’t have more today
It’s not necessary that those queries run automatically. On each parameter on the left pane you could have a refresh button when there’s a query attached to it. The user has to refresh to run query and see values.You can still keep the last queried values in the xml of the project (but it can be 1000 by parameter)
As we envision it at this point, this probably will be done via specifying a module output for a list of parameter values, not a query. A module would be a more versatile solution because it can include a query, or a text file, or something else.
Unfortunately not. This is something really missing in Easymorph as in real life a lot of parameters are dynamic, mostly depending on repository content.
Today you can try to generate dynamically your project through another project, filling possible values of parameters during generation in xml but its complex and remains dangerous when upgrading Easymorph.
A quick update on this topic. We've finally decided that this feature request will be addressed by adding run-time user inputs. Run-time user inputs seem to address many needs, including this one, and will be a versatile feature all around.
Not sure it will solve the problem. I mean if the user input can be pre-defined with database values it's ok, else it's not.
You must understand that an end-user does not necessarily know about the possible values inside a column of a table. So he wants to see the values inside a combo box and then pick one. Imagine long labels for example, you can type them with syntax errors.
Proposing already input values is not a complete solution because you can't see other database values and at the beginning, as you have not entered any value yet, "already input values" is empty.
Yes, user input will be available on the Server too - in tasks and Catalog computations. When a workflow will reach the "User input" action, it will pause and its status will indicate that user input is required. Clicking the computation/task would bring up a dialog similar to the parameter dialog that is now shown when a task is started. After input values are submitted by the user, the workflow will continue running. So from a UI perspective, it will be like a prompt for parameters, just in the middle of a workflow.
