"Strongest" way to pass multiple parameters.

[Drew Sanderson]

What do you feel is the "strongest" way to pass multiple parameters to scripts in FileMaker? I am currently using using Ray Cologon's DeclareVariables but I think that some of the text I am passing is in the same pattern as the function is expecting, therefore breaking the text in the parameters. I am thinking that a solution that more resembles xml would be better.

So....

What are all the cool kids using these days to robustly pass multiple parameters. I am looking for the solution that is least likely to break ( Due to text parsing errors?) .

Thanks,

Drew

[Vaughan]

Text parsing error occurs when the text contains the delimiter characters. Work out what the delimiter characters are and make sure the parsed text does not include it.

[doughemi]

The pipe character | (shift-backslash) works well, because it is easily human-readable and is not real likely to be found in any parameter.

[Drew Sanderson]

I probably should not have added the part about text parsing errors as the above replies although true, are not directly relevant to my question.

Other solutions I have seen like Ray's are like those from Six Fried Rice @ http://sixfriedrice.com/wp/passing-multiple-parameters-to-scripts-advanced/

Other options out there I am not aware of?

[Tim W]

Hi Drew,

I first latched-on to using a simple string syntax with a "¶" between each element and using a shorthand custom function like http://www.briandunning.com/cf/581 GSP() for extraction. It is simple and powerful with the only exception so far that paragraph text needs a helper function to substitute the "¶" on each end to preserve the element. I like the SFR concept, but have not really warmed up to it's use. An XML style format has also occurred to me as a possiblility with the self describing nature of XML, but thus far simple has won out.

Tim

[jbante]

The two main schools of thought for passing multiple script parameters are return-delimited values and name-value pairs — the choice is a matter of taste, whether you prefer array or dictionary data structures. Both approaches have solutions for dealing with delimiters in the data. For return-delimited values, you can use the Quote function to escape return characters, and Evaluate to extract the original value:

this standard. As long as you have a function to define a name-value pair in a parameter (# ( name ; value)) and another function to pull specific values back out again (#Get ( parameters ; name )), it works, and all variations should behave the same way. Any other supporting functions are purely for convenience, and probably can be re-implemented for whatever representation syntax you want. So I'd write:

Quote ( "parameter 1") & ¶ & Quote ( "parameter 2¶line 2" )

will give you the parameter:

"parameter 1"

"parameter 2¶line 2"

and you can retrieve the parameters:

Evaluate ( GetValue ( Get ( ScriptParameter ) ; 2 ) )

with the result:

parameter 2

line 2

Every name-value pair approach worth using has it's own approach for escaping delimiters. In my own opinion, XML-style syntax is unnecessarily verbose. My personal preference when working with name-value pairs these days is "FSON" syntax (think "FileMaker-native JSON"), which is where the parameters are formatted according to the variable declaration syntax of a Let function:

$parameter1 = "value 1";

$parameter2 = "value 2¶line2";

I only consider name-value pair functions practical when the actual syntax is abstracted away with custom functions. Once you do that, the mechanics of working with the different types should be interchangeable, such as any name-value pair function set that matches 

# ( "parameter1" ; "value 1" ) & # ( "parameter2" ; "value 2¶line 2" )

and:

#Get ( Get ( ScriptParameter ) ; "parameter2" )

I only have 2 requirements for any parameter-passing syntax: 1. It can encode it's own delimiter syntax as data in a parameter, and therefore any text value (already mentioned in this thread), and 2. it can arbitrarily nest parameters, i.e., I can include multiple sub-parameters within a single parameter. The requirements tend to work hand-in-hand with each other. If I can do those two things, I can construct everything else I will ever need within that framework.

[Drew Sanderson]

Nice post Jeremy! I will chew on it for a bit.

[LaRetta]

Nice explanation, Jeremy.

I would only add to the overall discussion my agreement to Vaughan and Doug's suggestion that if you use a delimiter be sure it is not common. The return (¶) is much too common and it has caught me before ... best to use a strange character. I use tilde ~.

[bcooney]

fwiw, I use | and cf's to parse. I usually set $vars to the params at the top for clarity and also include what the script expects in its name, for example: New Activity ( parentID|typeID)

[LaRetta]

I do all that too - thanks for bringing it up! I guess I use tilde because the pipe is difficult to see amongst characters whereas tilde makes its location obvious when being viewed by people with poor eyesight.

Setting $p with the script parameter is great idea I picked up from Mr_Vodka.

[bcooney]

Yes, tilde is nice and visual. Hmm...change everything now? Perhaps next project.

Yes, verbosity is a developer's friend down the road!

[jbante]

I wouldn't be so cavalier in casting aside ¶ as a delimiter. No matter what delimiter character you use, there's the possibility that that delimiter will be part of some parameter you want to pass in the indeterminate future. Escape sequences are a more robust solution than increasingly obscure characters. (This is not to say I'm innocent myself; Unicode music symbols used to be a favorite of mine.) The nice thing about ¶ as a delimiter is that the built-in FileMaker functions already give us everything we need to escape and parse arbitrary text without custom functions. GetValue, Quote, and Evaluate are your friend. And it's hard to beat ¶ for visually distinguishing values. It might be worth someone's time to write a custom function or two for building and parsing return-delimited lists so they don't have to think about when to Quote() and Evaluate() their script parameter values and when not to.

I agree that verbosity is a developer's friend, to a point. The helpful verbosity in name-value pairs is why I prefer them to return-delimited lists (when it's my choice). However, XML requires redundant information in order to be syntactically correct:

<parameter1>value1</parameter1>

Why can't "</parameter1>" just be "</>"? Well, in XML the paired tag is helpful for readability since XML is designed as a document markup language, and who knows how long the text between opening and closing tags will be? However, when we're talking about passing multiple parameters, what we're doing is closer to object serialization than document markup; so perhaps YAML and JSON might be better sources of inspiration. I'm happy only seeing the name for a name-value pair once.

[LaRetta]

Nah, I'm not putting down the ¶ at all, LOL. It's just that I've used a process which applied to strings without carriage returns so I'm (lazily in my case) chosen ¶. Then a year later, a requirement changes and a second paragraph is allowed in the field and we may remember to change the auto-enter field definition but not the parsing process deep within a script somewhere.

And when I have/use script parameters to hold the values, if later I decide to change that parsing character to allow scope creep then I have to find those fields. If we plan for the most obscure and we maintain verbosity to the max, we are in like thieves.

[LaRetta]

To get to the my point a bit better ... it is easier for me to know to take my always-used, unique-in-99.9% symbol and turn it into a carriage return when/if I need it than to try to split data by text which ends up with a carriage return (which is quite common) particularly when dealing with large volumes of unknown text such as migrations.

[David Zakary]

I modified a CF from Briandunning.com and have been using it for several years. I use the vertical pipe as a separator. I retrieve the parameter with GSP (x), where x is whatever parameter number I need.

IIRC, Todd Geist wrote a blog post a while back against the use of the name-pair format - basically it was too much to manage.

[Fitch]

Interesting discussion. Really excellent posts, Jeremy.

Here's Todd: Passing Multiple Parameters. I get where he's coming from, but I still prefer name/value parameters. (It's a shame, when he moved his blog we lost this great discussion thread that came out of his original post.)

Here's my post from last year: Passing multiple script parameters. Still my go-to method.

[Wim Decorte]

I prefer name/value pairs. For a very simple reason: in an environment where I need to debug or continue work on somebody else's work it is very easy to see what parameters they are passing for what purpose instead of seeing a meaningless list of values for which I need to read the rest of the script to see where they are being used in.

The added benefit is that you can pass optional parameters and pass the parameters in any order without having to cater for the exact order of the values.

Bruce R has a nifty CF that automatically parses the passed parameters to variables in the receiving script.

Regardless of the parameter passing technique that is being used, it is important to document the parameter expectations in the script. Be kind to yourself and others :)

[Geoffrey Gerhard]

Just stumbled on this thread and a related post on github.com/filemakerstandards. Having "rolled my own" years ago, it was interesting to discover that most practitioners end up in (more or less) the same place. I'm curious on one point: are there any "truly safe" delimiters? Corn Walker mentioned Char ( 2 ) and Char ( 3 ) at the POE NY as likely candidates (apparently they're teletype characters), and I've been using them ever since. Never seen them in the wild, and substitute them for null in all value parameters.

Curious if anyone thinks these (or anything else) cross the threshold from "obscure" to "bulletproof." Is there a case where their deletion could be relevant to the utility of a field's value?