Hey, cool! We do the same thing. Very handy.

I duplicated the GetParameter function called it ExitParameter. I simply replaced the Get(ScriptParameter) with Get(ScriptResult) and voila, I can extract all my parameters with the ExitParameter function and just continue in my main script.

Now I am busy re-writing my scripts.
Thanks a lot.

kind regards

Regine

I think that’s a great idea.

When I did the very first iteration of this whole set of ideas back when 7 was released, I used a JSON-like syntax, but not really JSON (it was actually based on OSX text plist format…). But it was harder to parse and produce.

Jesse built these from scratch with a few key goals in mind:

1: Resilient. I should be able to put any data, any characters, and any type into the dictionary without errors. (Container data being the notable exception.)

2: Nestable. I should be able to do #("x", 1) & #("y", #("y1", 2) & #("y2", 3)) with impunity.

1: Decent performance (no character-by-character recursive processing)

So the question is, can we meet these goals with JSON? I’m not sure… I’m not entirely sure how big a deal #3 is, too. I feel like it would be unacceptable to do this kind of recursion but I may be wrong.

Geoff

But the more I think about it, the more I conclude: we’re doing pseudo-JSON. (Maybe it’s JXSMOLN) Why not just use JSON? Then for instance if we throw it into a web viewer, and maybe the web viewer uses a jquery library – it all just works.

A lot of people tell us about that technique. I, for one, *prefer* to have my variables and parameters in separate name spaces. It prevents the possibility that a parameter passed to a script could impact its functioning in unexpected ways down the road. If I request a parameter called “XYZ” I know I’ll get a passed parameter, and not a variable. But I can see either side of this argument.

I will say, though, that I agree that parameters are used so heavily that it should not be hard to type. That is why we use a function called # to pass parameters:

#("p1", 10) & #("p2", "boo")

and #P to fetch them:

#P("p1") & " and " & #P("p2")

It is certainly more characters to type than $ but still quite efficient.

Geoff

Hi Everyone,

we have several systems (a few hundred fm-systems, which date back (partially) to 1992 with more than 70 fm-files). Using a custom-function is in such cases not an option and the amount of custom-builds is so much that rebuilding isn’t an option either.
With that in mind my collegaes and i use a different method, which is pretty easy to implement:

We call our script with either a script or a button with a scriptparameter which consists of multiple values:
[code]
“$value1="&quote(value_x)&”;$value2="quote(value_y)&etc.etc.
[/code]
The script that is called has a step that sets a variable $result with the following calculation:
[code]
Evaluate( “Let( [” & Get( ScriptParameter ) & “]; ” & 1 & ” )”)
[/code]
The nice thing is that this step creates local (or global if you like with $$) variables that you can use in the script.

Putting the “quote()” around the values ensures that the evaluate also works when one of the vars is empty. Using the quote() makes the function be read a little eassier than with escaped “\”” quotes (this of coarse is a matter of opinion )

The downside of this method may be that all the vars are evaluated as text .. in such cases you will have to change them back to numbers, dates, or wathever you need them to be. If you are sure a value is never empty you can of coarse parse it without the quotes, a date or a number will not need to be reformatted as text then.

If you were to use this function is several cascading script you could exit a script with in the ScriptResult:
[code]
Get ( ScriptParamer )&”;$value5="quote(value_z)&etc.etc.
[/code]
and if one of the original values changes in this script, you could simply add that value again to the parameter …. when evaluating the last (identical named) value in the parameter will be the resultvariable

cheers, Menno

we have several systems (a few hundred fm-systems, which date back (partially) to 1992 with more than 70 fm-files). Using a custom-function is in such cases not an option and the amount of custom-builds is so much that rebuilding isn’t an option either.
With that in mind my collegaes and i use a different method, which is pretty easy to implement:

We call our script with either a script or a button with a scriptparameter which consists of multiple values:

“$value1=&quote(value_x)&”;$value2=quote(value_y)&etc.etc.

The script that is called has a step that sets a variable $result with the following calculation:

Evaluate( “Let( [" & Get( ScriptParameter ) & "]; ” & 1 & ” )”)

The nice thing is that this step creates local (or global if you like with $$) variables that you can use in the script.

Putting the “quote()” around the values ensures that the evaluate also works when one of the vars is empty. Using the quote() makes the function be read a little eassier than with escaped “\”" quotes (this of coarse is a matter of opinion )

The downside of this method may be that all the vars are evaluated as text .. in such cases you will have to change them back to numbers, dates, or wathever you need them to be. If you are sure a value is never empty you can of coarse parse it without the quotes, a date or a number will not need to be reformatted as text then.

If you were to use this function is several cascading script you could exit a script with in the ScriptResult:
Get ( ScriptParamer )&”;$value5=quote(value_z)&etc.etc. and if one of the original values changes in this script, you could simply add that value again to the parameter …. when evaluating the last (identical named) value in the parameter will be the resultvariable

cheers, Menno

Thanks for the heads up. Alas, the cleanup process isn’t as simple as one would hope. Wordpress seems to have incorrectly interpreted UTF-8 data as Latin-1, then re-transcoded it to UTF-8. This happened with our last upgrade (using their built in import/export functions). The end result is we have valid UTF-8 content, properly encoded and displayed, which contains wacky characters.

Fixing it requires correcting each problem case. Some day I’ll get a script written to do this for me.

Thanks,

Geoff