Re: [DataVision-users] Script Language support & strings containing quotes

[Jim M. <ji...@io...>]

Charles Whittington wrote:
> I think the problems start earlier than that .. suppose
> 
> {APP.T1.STATUS}
> 
> get substituted with
> 
> Frank's Reply
> 
> for example. When you pass that to a scripting language you are in trouble already.
> 
> If you pass %q{Frank's Reply} you are OK, but {APP.T1.STATUS} contains %{Frank}s Reply} you are back in difficulty again. Isn't that right, Jim?
> 
> I have attached the previous thread below to save you looking it up ;)
> 
> Charles
> 
> 
> Jim Menard wrote:
> 
> 
>>> Charles Whittington wrote:
>>>  
>>>
>>  
>>
>>>>> A production report of mine has a suppression condition (also occurs as 
>>>>> part of an if ( ....) ) which looks like this:
>>>>>
>>>>> '{Txn.Notes}' == ''
>>>>>
>>>>> which is fine until a user unhelpfully puts a ' or " into the Notes 
>>>>> field, at which the report gives a "BSFException". It is clear that the 
>>>>> ' in the Notes is terminating the string to be compared. 
>>>>>
>>>>> I can change it to
>>>>>
>>>>> "{Txn.Notes}" == ''
>>>>>
>>>>> but then when the user has " in the string it gives the same error.
>>>>>
>>>>> I have Googled quite a bit but I cannot find a hint on how to get round 
>>>>> this in Ruby and/or Datavision. I have tried {Txn.Notes}.empty?  but 
>>>>> this also gives a BSFException.
>>>>>
>>>>> I am afraid my Ruby knowledge is lacking - but I have read the Ruby 
>>>>> manual page on strings but it seems more to so with the way DV presents 
>>>>> the string to the Ruby interpreter - does anyone have a ready-made solution?
>>>>>    
>>>>>
>>>    
>>>
>>>
>>> You are correct, it's the way that DataVision presents the string to Ruby. 
>>> DataVision is plopping the value of the column right into the Ruby source. You 
>>> could use %q or %Q, like this:
>>>
>>>   %q{Txn.Notes} == ''
>>>
>>> but then you have to worry about strings that have "}" in them. With %q 
>>> (single quote) and %Q (double quote), you can use "{}", "[]", "()" or "<>" as 
>>> the delimiter. You can use any other character, too, but then you use it on 
>>> both ends like this:
>>>
>>>   %q/Txn.Notes/ == ''
>>>
>>> There's a Catch 22 here: unless you know what might be in the string, you 
>>> can't escape it. This is a big flaw in DataVision, again because it's plopping 
>>> the column's value into the Ruby source. DataVision could just turn everything 
>>> into strings, I suppose, and worry about the escaping itself. That probably 
>>> isn't the right thing to do for non-string columns (numbers, dates), though.
>>>
>>> I hope this helps.
>>>
>>> Jim
>>>  
>>>
>>  
>>
> 
> Hmmmmmmm! Is that really true? If DV is plonking the string straight 
> into the interpreter, can it not apply the logic (using "{Txn.Notes}" as 
> an example):
> 
> The writer would like the string in Txn.Notes to be passed to Ruby. If 
> that string contains a ", I must escape it. So if the author writes
> 
> %q/{Txn.Notes}/
> 
> then the / must be escaped. This would not harm "{Txn.Amount}", or 
> %q/{Txn.Date}/ (which might well contain /) would it?
> 
> As it stands I can't see a solution because, if I have understood it 
> correctly, we (DV authors) can't even test whether the string contains 
> the character we are thinking of using as a delimiter!
> 
> Or have I missed something?

The real right thing to do is to expose the columns, parameters, formulas, 
etc. as script objects just like the report object is exposed. Since the 
report is already exposed to the object, you should be able to write something 
like this in your scripts (Ruby example here):

   my_col = $report.value("table.column") # only columns don't need "{}"
   if my_col == null
     my_col = 'something special'
   end
   my_param = $report.value("{?My Parameter Name}")
   # ...

Jim
-- 
Jim Menard, ji...@io..., http://www.io.com/~jimm
"Any sufficiently advanced technology is insufficiently documented."
     -- kabdib on slashdot