I agree...I think that the syntax of escaping as it
currently is, is awkward...although it's definately an
improvement from where we were with url encoding. One
point of clarification...The regex function would look
like:
${__regexFunction("[hH]ello\, [wW]orld",\$1\$,1,,,)}
A bit better.
The only way we can go to what you two are proposing
is by taking the responsibility of escaping characters
out of the function helper dialog and giving it to the
users (not a big deal). What this will do is allow
CompoundVariable to not have to deal with escaped
characters (or simply ignore them) and parse strings
as if they were not encoded. The functions themselves
will have to handle decoding the strings, or
CompoundVariable can decode when execute() is called.
I don't think we'll be able to help that previously
generated functions will have to change. The reason is
that the parser has to know whether the string is
encoded or not. We tried it where CompoundVariable
simply tried to decode the string...The idea was that
if the string isn't encoded it should stay the same,
right? Well, no. Especially in the case of the
JavaScript function. If the script is something like
"1+${i}" The + gets translated to a space, resulting
in "1 ${i}" which isn't a javascript statement
obviously.
These are my thoughts.
Thad
--- "BAZLEY, Sebastian"
<[EMAIL PROTECTED]> wrote:
> > -----Original Message-----
> > From: Mike Stover [mailto:[EMAIL PROTECTED]
> > Sent: 11 March 2003 18:36
> > To: JMeter Developers List; [EMAIL PROTECTED]
> > Subject: Re: Changes in function
> >
> >
> >
> > > Of coarse...The only problem I have with it is
> that it
> > > puts the job of encoding the strings on the user
> > > instead of the function helper dialog. Let me
> think
> > > about it for a bit. Any other opinions?
> >
> > Maybe a better example would help.
> >
> > consider:
> >
> > (unencoded) - ${__regexFunction("[hH]ello,
> [wW]orld",$1$,1,,,)}
> >
> > now, it appears to me, your way actually requires
> the
> > encoding look like:
> >
> > ${__regexFunction("[hH]ello,
> [wW]orld"\,\$1\$\,1\,\,\,)}
> >
> > And I'm saying, encode the string literals
> instead:
> >
> > ${__regexFunction("[hH]ello\, [wW]orld",$1$,1,,,)}
> >
> > -Mike
> >
>
> <aside>
> It would be nice if it were not necessary to quote
> the "," in the text
> string above.
>
> Perl has some useful quoting mechanisms:
>
> q(), q[], q{} etc - quote the enclosed text with no
> further substitutions
> qq() etc - quote, but allow interpolation
>
> Not sure if these would be easy to implement - it
> would require knowing
> where a string was acceptable.
>
> If the current parser already "knows" when it is
> processing a parameter
> list, function name etc, then it might be possible
> to use that information
> to process the next part of the string more
> "intelligently".
>
> </aside>
>
> I agree with Mike that only unusual situations
> should require escaping.
> [And if the regular expression requires escaping,
> won't the user already be
> familiar with the required techniques?]
>
> Also, what about existing scripts?
> Will these not have to be changed if the syntax
> changes?
> This could cause a lot of grief for us...!
>
> How about allowing the user to change the list of
> special characters for a
> particular string?
> This could be done by supplying an extra field at
> design time (saved with
> the test script, and defaulting to the ones used
> now).
>
> This would be backwards compatible ...
>
> --
> Sebastian Bazley <[EMAIL PROTECTED]>
> The opinions expressed herein are my own, and are
> not necessarily endorsed
> by my employer ...
>
>
>
_________________________________________________________
> This email is confidential and intended solely for
> the use of the
> individual to whom it is addressed. Any views or
> opinions presented are
> solely those of the author and do not necessarily
> represent those of
> SchlumbergerSema.
> If you are not the intended recipient, be advised
> that you have received
> this email in error and that any use, dissemination,
> forwarding, printing,
> or copying of this email is strictly prohibited.
>
> If you have received this email in error please
> notify the
> SchlumbergerSema Helpdesk by telephone on +44 (0)
> 121 627 5600.
>
_________________________________________________________
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
