WebDialog parameters passed to callback cause .to_l error
-
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. -
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 /> </span><span class="syntaxdefault"></span>
This allows me to handle pretty much anything the users enters.
-
isn't it faster to test for true
def self.decimal_separator [1.1].length == 2 ? ',' | '.' end#def
john
-
Guys
This place is a great source of information.
-
@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)
-
@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.
-
@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.
-
Had this idea today:
separator = (1/Float(2)).to_s[1]
-
even shorter
separator = Float(1).to_s[1]
-
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...
Likesep = (begin;'1.0'.to_l;'.';rescue;',';end)
So if sep==',' we present decimal numbers differently using something liketr('.',',')
?
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 alwaysx_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 firstsep==...tr...
still applies to ensure it's locale friendly... BUT then thex_length = x.to_l
must be used Ruby-side...
Advertisement