woofy31 Posted March 23, 2013 Posted March 23, 2013 (edited) Hey guys, Say I make a Script Filter and link it to 4 script actions that each perform a different function, but each action needs a different input from the Script Filter, and this is where the problem begins, because the "arg" attribute can hold only one value which will work with just 1 of the 4 actions Right now the only workaround to this problem is to give the "arg" attribute a separated list of multiple values, and then each action would need to parse the input and search for its piece of data, but it's too much parsing and splitting involved.. My opinion is that we should have some freedom in the XML attributes of the feedback results by letting us define our own attributes in a result and Alfred would automatically send those attributes as individual parameters to the "alfred_script" function, as well as individual {attribute_name} to other predefined actions. For example, script filter would generate this xml result: ... <item uid="rdioartist" arg="r96664" valid="yes" autocomplete="Incubus" artistiname="Bjork" track="All is full of love"> ... And we, the programmers, would then use the following in script action: on alfred_script(arg, artistname, track) -- we use the parameter that is needed for a specific action end alfred_script [later edit]: a big problem with the current design is when you link a script filter to multiple actions AND a Notification action, because inside the Notification action we can't split the separated list of values of the "arg" attribute, and setting the arg attribute to a single value would make the other actions useless So with my suggestion above we would type something like {aristname} or {track} inside the Notification action Edited March 23, 2013 by ursanrazvan
jdfwarrior Posted March 24, 2013 Posted March 24, 2013 Hey guys, Say I make a Script Filter and link it to 4 script actions that each perform a different function, but each action needs a different input from the Script Filter, and this is where the problem begins, because the "arg" attribute can hold only one value which will work with just 1 of the 4 actions Right now the only workaround to this problem is to give the "arg" attribute a separated list of multiple values, and then each action would need to parse the input and search for its piece of data, but it's too much parsing and splitting involved.. My opinion is that we should have some freedom in the XML attributes of the feedback results by letting us define our own attributes in a result and Alfred would automatically send those attributes as individual parameters to the "alfred_script" function, as well as individual {attribute_name} to other predefined actions. For example, script filter would generate this xml result: ... <item uid="rdioartist" arg="r96664" valid="yes" autocomplete="Incubus" artistiname="Bjork" track="All is full of love"> ... And we, the programmers, would then use the following in script action: on alfred_script(arg, artistname, track) -- we use the parameter that is needed for a specific action end alfred_script [later edit]: a big problem with the current design is when you link a script filter to multiple actions AND a Notification action, because inside the Notification action we can't split the separated list of values of the "arg" attribute, and setting the arg attribute to a single value would make the other actions useless So with my suggestion above we would type something like {aristname} or {track} inside the Notification action Perhaps you could try to simply split the functionality into several pieces rather than trying to merge so many different functions into a single script filter. If that is not desired, splitting the argument based on a predetermined delimiter should still be extremely easy to execute.
woofy31 Posted March 24, 2013 Author Posted March 24, 2013 Perhaps you could try to simply split the functionality into several pieces rather than trying to merge so many different functions into a single script filter. If that is not desired, splitting the argument based on a predetermined delimiter should still be extremely easy to execute. Splitting the functionality into several pieces would create a lot of duplicate code as for splitting the argument, yes, it's easy to execute, but what do I do if I want the arg="r9996,bjork,all is full of love" sent to both a script action & a notification output? the script will handle the splitting with no problem, but the notification output will take the arg as a whole unless I first put it through a script action, which again creates more code than I first wanted Don't you agree that the above proposed suggestion would open so many more possibilities? just imagine not being limited to "{query}" in actions and outputs...
Tyler Eich Posted March 24, 2013 Posted March 24, 2013 Splitting the functionality into several pieces would create a lot of duplicate code as for splitting the argument, yes, it's easy to execute, but what do I do if I want the arg="r9996,bjork,all is full of love" sent to both a script action & a notification output? the script will handle the splitting with no problem, but the notification output will take the arg as a whole unless I first put it through a script action, which again creates more code than I first wanted Don't you agree that the above proposed suggestion would open so many more possibilities? just imagine not being limited to "{query}" in actions and outputs... Connect the script filter to a Run Script action. Put a few lines of code at the end of the script action that parse the query and echo a formatted output. Connect the script action to the notification. As for duplicate code, check out my Colors workflow. It uses one file for all its code, and implements a switch to determine what blocks to use. I haven't found {query} limiting at all
woofy31 Posted March 24, 2013 Author Posted March 24, 2013 Connect the script filter to a Run Script action. Put a few lines of code at the end of the script action that parse the query and echo a formatted output. Connect the script action to the notification. As for duplicate code, check out my Colors workflow. It uses one file for all its code, and implements a switch to determine what blocks to use. I haven't found {query} limiting at all I just wanted to avoid making intermediary script actions to parse input to be sent to a notification - I wanted to send the data directly to the notification output itself, and you must agree that it's tempting to have more than just "{query}"
effe Posted May 14, 2015 Posted May 14, 2015 Sorry for the necro-post, but I was just wondering the same thing. Any way we can have multiple argument fields to pass around? currently it's <arg>...</arg> but it'd be so great to have: <args> <arg></arg> <arg></arg> <arg></arg> <arg></arg> </args> or even better maybe just an attribute and still allow multiple arg tags as long as they're distinct <arg modifier="none">foo</arg> <arg modifier="cmd">bar</arg> <arg modifier="ctl">baz</arg> <arg modifier="shift">foo bar baz</arg> and to be backward compatible, <arg>foo</arg> == <arg modifier="none">foo</arg> Yes!?
deanishe Posted May 15, 2015 Posted May 15, 2015 We've talked about this before, and I think Andrew is looking into something along the lines of: <mod key="cmd"> <arg/> <subtitle/> ... </mod> Currently, your best solution is probably to encode all the values you need to JSON and pass that in arg. Then you can decode it in the next script and extract just the data that script needs.
deanishe Posted May 15, 2015 Posted May 15, 2015 (edited) I found the thread where we talked about a way to specify alternate values for arg, subtitle, etc. I also remembered the workflow where I had this exact problem. Each item has two URLs, one for the page/article/whatever and one for the corresponding comments thread. I stuck them both in a dictionary, encoded it to JSON and put that in arg. Each action it's connected to needs to pull something different out of the JSON, so they're all slightly different, but you can minimise code duplication with this pattern: script.py --key post_url "{query}" # Where {query} will be replaced by the JSON data script.py pulls out and actions whatever it finds in the JSON data under post_url. That way, you only have to edit the --key argument in the Run Script actions and not the script itself. Another similar solution, which would be better if there is a large amount of data associated with each item, is to cache the current set of results (if you're using a Script Filter) and pass the id of each result in arg. Whichever script gets run next can then extract the data it needs from the cache based on the id. Edited May 15, 2015 by deanishe
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now