WebDialog parameters passed to callback cause .to_l error

[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]

[TIG]

But that Ruby float as a string is ALWAYS going to return "1.0", so it always sets as "." even when the user's day-to-day decimal-separator is ","
The issue is how the user input of "1,0" is correctly read as a float or a length.
In the UI 'input' the default input type pretty much sorts that out.
Since 1.0.m displays as 1.000m or 1,000m depending on the user's locale [and of course the model's unit settings]
In a webdialog it's more awkward, because all input is a string that needs 'interpreting'.
So the earlier posts' trickery using lengths etc to get the real separator would help...
Certainly when initially populating the webdialog with decimal values...
Like sep = (begin;'1.0'.to_l;'.';rescue;',';end)
So if sep==',' we present decimal numbers differently using something like tr('.',',')?
But surely some leeway could be used...
What if a user first inputs x = 1.0 then x = 2,3 ?
Should BOTH be acceptable ?
So assuming they are expected as floats...
if sep=='.' x.tr!(',','.') else #',' x.tr!('.',',') end
For the display-side this makes either typed in separator suit the the 'locale', but on the Ruby-side, it's always x_float = x.tr(',','.').to_f
For inputted 'lengths' it is different, because the Ruby-side expects it to be in the locale separator format...
The first sep==...tr... still applies to ensure it's locale friendly... BUT then the x_length = x.to_l must be used Ruby-side...