WebDialog parameters passed to callback cause .to_l error

Jim

It is curious, and there is a lot going on behind the scenes. This document explains some of what is going on.

You are relying on the WebDialog (and HTML specifications) to put together your form data. The form data is sent to the Ruby script as one string. There is a limit to the length the string may be. The browser replaces spaces with + signs and and possibly other substitutions. Form data is appended to the string in order they appear in the form with a & and a name/value pair separated by =.

The problems start if you need to pass any of the symbols +, space, &, or = from the web dialog form to your Ruby script. You will find the form data difficult if not impossible to parse on the Ruby side. Here is a contrived example:

Because of these limitations, most folks have adopted some alternative method of data serialization to encode the form data such as JSON or Base 64 encoding, all of which require some use of JavaScript to process the form data prior to sending it to the Ruby script.

Jim

@jolran said:

How bout .to_f.to_l ?

Careful..

"1".to_l ==> 1.000000cm

"1".to_f.to_l ==> 2.540000cm

jolran

Yes, that is a side effect. If one would take that approach...

It may be worth to mention "1.0".to_l doesent work either..

I think it's debatable using forms at all..
Passing onclick events to functions gives more options parsing the strings before sending them to Ruby..

driven

@jim said:

...Commas do not make good value separators because some languages use commas where we would use a decimal point in a number...

can something like this be used to find the digit separator

      [1.1].length == 2 ? sep = "." ; sep = ","
      x,y,z = val.split(sep)

I also found if you use to_f to clean any non digit's up on the ruby side, you break to_l

i.e my input of 1 will become 25.4mm...

john

driven

@jolran said:

It may be worth to mention "1.0".to_l doesent work either..

"1.0".to_l 
=> 1.0mm

"1.0".to_f.to_l 
=>25.4mm

I missed a couple of post...

jolran

Ah yeah, Jim said that already.. I only looked at the code

puts "1.0".to_l still don't work for me.
Error: #<ArgumentError: (eval):258:in `to_l': Cannot convert "1.0" to Length>

driven

@jolran
are you still on v8...

jolran

Yes John. Still on 8. I havent had time to test the new good stuff..

Btw .to_s.gsub(".", ",").to_l worked for me in the node editor. But I can't remember if I did an eval on a hash_String before running that..
I havent touched the JS for a while...

Now seeing this I wonder if I got it all wrong, it seemed to work properly

edit: puts "1.0".to_l don't work(for me) on 2014 either. But it never has so I'm suprised you made it work. Maybe because your on Mac ?

Oh yeah and even how ugly it may look this works: eval("+1.0").to_s.gsub(".", ",").to_l
Then again I believe TS is not interested in hacks..

Jim

@jolran said:

edit: puts "1.0".to_l don't work(for me) on 2014 either. But it never has so I'm suprised you made it work.

Really? Does "1,0".to_l work?

jolran

@unknownuser said:

Really? Does "1,0".to_l work?

Yes.

Jim

A begin..rescue clause can be used to test this. For a one-off:


len = begin
  "1,2".to_l
rescue
  "1.2".to_l
end

p len

But obviously it would be better to write a method to handle this for more cases.

jolran

heh yeah that works to.

Don't know if it's prettier than a gsub, but if it works..

Does the code pass through transparently if no errors, or does this add overhead?

It might be interesting to do a speed comparing against gsub variant.

@unknownuser said:

But obviously it would be better to write a method to handle this for more cases.

Yeah, but sometimes one run into corners where direct evaluation is necissary.
Like get_element_value at some odd place where not possible to go through normal routine.

jiminy-billy-bob

I use this :

<span class="syntaxdefault"><br />def self</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">decimal_separator<br />        </span><span class="syntaxstring">'1.0'</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">to_l<br />        return </span><span class="syntaxstring">'.'<br /></span><span class="syntaxdefault">    rescue ArgumentError<br />        return </span><span class="syntaxstring">','<br /></span><span class="syntaxdefault">end</span><span class="syntaxcomment">#def<br /><br /></span><span class="syntaxdefault">def self</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">to_l</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">str</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    return str</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">to_s</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">gsub</span><span class="syntaxkeyword">(/\</span><span class="syntaxdefault">s</span><span class="syntaxkeyword">+/,</span><span class="syntaxstring">''</span><span class="syntaxkeyword">).</span><span class="syntaxdefault">gsub</span><span class="syntaxkeyword">(/(\.|,)/,</span><span class="syntaxdefault"> self</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">decimal_separator</span><span class="syntaxkeyword">).</span><span class="syntaxdefault">to_l<br />end</span><span class="syntaxcomment">#def<br />&nbsp;</span><span class="syntaxdefault"></span>

This allows me to handle pretty much anything the users enters.

driven

isn't it faster to test for true


def self.decimal_separator
    [1.1].length ==  2  ?  ',' | '.'
end#def

john

jolran

Guys

This place is a great source of information.

jiminy-billy-bob

@driven said:

isn't it faster to test for true

Maybe It's widely fast enough for my use (Parsing one string at a time entered by the user)

tt_su

@driven said:

isn't it faster to test for true


> def self.decimal_separator
>     [1.1].length ==  2  ?  ',' | '.'
> end#def

john

You never know for sure until you profile the code. And in Ruby you get many surprises. That being said - unless you have a noticeable performance issue there is little need to pre-optimize.

Jim

@driven said:

isn't it faster to test for true


> def self.decimal_separator
>     [1.1].length ==  2  ?  ',' | '.'
> end#def

john

Maybe I do not know off-hand. This is code you would run at most one time in a plugin to determine which separator to use so it isn't terribly important to optimize.

The code that actually performs the conversion may need optimized especially if there are many conversions to do.

Jim

Had this idea today:


separator = (1/Float(2)).to_s[1]

driven

even shorter

separator = Float(1).to_s[1]