I agree with you on everything except that encoding the the dollar signs as you do
seems
inconsistent with the encoding of commas. The $'s should only be escaped if they are
meant
as a literal part of the template (the way the comma is escaped). That would be more
consistent, I think.
-Mike
On 11 Mar 2003 at 13:14, Thad Smith wrote:
> 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]
>
--
Michael Stover
[EMAIL PROTECTED]
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
