Meaning that any URL parameters that are not reserved by the URL scheme would be available within the triggered workflow as set variables.
Barring that, perhaps a means to get the URL used to invoke a workflow through something like workflow.get_url()?
- Rod
Interesting idea, though I'm somewhat reluctant to allow arbitrary parameters in editorial:// URLs, since I might add new "reserved" parameters in the future...
If you're open to scripting, an alternative might be to encode multiple parameters as JSON in the input parameter, and "unpack" them in a script (using the json module). Whether that's a feasible approach also depends on the app that launches the URL of course...
I am open to scripting, and almost mentioned the currently feasible "unpacking" method in my post. :-)
My gut feeling is that JSON would be tough to do in most calling apps, so I'd have to do my own parsing on the receiving end, but it'd probably be a good enough approach in simple cases.
How about a reserved URL parameter prefix for user variables?
Something like editorial://?command=MyWorkflow&usr_myVar=foo, which then does workflow.set_variable('myVar', 'foo') in MyWorkflow's environment before running it.
That way, I could add as many usr_ prefixed variables as I like, and you'd only have to avoid using that prefix in future keywords.
A prefix might be an option, I could imagine using something like var-xyz=foo to set the variable xyz... I probably won't change the URL scheme in the next update, but I'll keep this in mind.