[tools 2.0] ValueParser.getStrings splits on comma?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
I'm not sure if I've used ValueParser.getStrings before (really,
ParameterParser.getStrings, in this case), but I'm surprised by what
is happening. Is this expected?
Request POST parameters:
foo=bar&comment=This, is a comment.
Velocity template code:
#set($comments = $parameterParser.getStrings('comment'))
#if(0 < $comments.size())
#foreach($comment in $comments)
#htmlEscape($comment)
#end## foreach
#end## if(comments)
I would expect this to produce a single element with the
text "This, is a comment." in the text area. Instead, I get two
elements, one containing "This" and the other containing
"is a comment.".
That seems ... crazy to me. I'm sure I can just change:
#set($comments = $parameterParser.getStrings('comment'))
to
#set($comments = $request.getParameterValues('comment'))
... but I figured that ParameterParser would do the same thing, no?
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJZm4ISAAoJEBzwKT+lPKRYKnUP+wQ0ZrGhe4R5X2tCi2nmrzJW
mgb1fqmBOd5m7TPz9iJnfj6jtLlK2u2u0cPp3BHsFyu8Y4RX5heC1RZ6fJfOPFx1
Tq5t3JXDoK0XmOL7/VI7R5eadQww9LDbdwR10Gl7Qch9IAfsgYNINIgZwGC1OawD
kXTc6m8lwKlvBnI7biyncDVY3pOoojh7EQNI6/sh1/hR2n2R35Fa9mpK7Y0Tjk/K
VkvhqLcuTqii3zlGTBTS0Zzn9XE5+jzFn7wNWmrdbmMYMKKyQCne7gvzH5j3RnK+
S9jAO/WVazKp2qI7xcAqg1upjqVfP9Rtg/cZOf0hR3swbe5+kJJcP2uw7YEDPGI0
orFGiIVRTI8+d1FwD4rsn6uoke43p/UVm/2McCkXTkWrvcZ29BLIyin6W+i4/Z6D
iDciX12YPD/abFsGqMEgAw4CG6WkvlZQnsAtQAtHW5EiDR4DpQQsjeYWxCE+O6SH
r0lUhGxzed9vBR1M4l5DbnbXRaLJ+kjjZRuDPDLlfXIisD9szdgGOOG8r1dWggaa
yZXGD/jN6MdnGp12xx7x53+RNqwAPx6o3SJqhJFUxHmOmShIOesoGdv/OsHQk4ep
tnnlJ8c7bE8oRsH4nT3VxSymY0GCIJFzWvUr2/2lw2wSHW6Om5JoampBamerhmdk
Lcqksts97wZmYrx+idl4
=w9Ic
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
Re: [tools 2.0] ValueParser.getStrings splits on comma?
Yeah, that's not ideal. You can configure the string delimiter in your tool
config. But this seems like surprising behavior for a ParameterTool to
have. The dangers of inheritance, i think. ConversionTool and ValueParser
are both built with formats in mind where it makes sense to watch for
delimited lists. ParameterTool works with inputs where lists have multiple
entries of the same key, instead of delimited values for a single entry. It
is convenient to share the interface and conversion code, but we should
probably change ParameterTool to act as expected by default.
Care to open an issue for this? Or maybe even patch it? :) I may have time
this week, but can't be sure.
On Mon, Aug 21, 2017 at 6:00 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I'm not sure if I've used ValueParser.getStrings before (really,
> ParameterParser.getStrings, in this case), but I'm surprised by what
> is happening. Is this expected?
>
> Request POST parameters:
> foo=bar&comment=This, is a comment.
>
> Velocity template code:
>
> #set($comments = $parameterParser.getStrings('comment'))
> #if(0 < $comments.size())
> #foreach($comment in $comments)
>
> placeholder="$msg.label.optional_comments">#htmlEscape($comment) ea>
>
> #end## foreach
> #end## if(comments)
>
> I would expect this to produce a single element with the
> text "This, is a comment." in the text area. Instead, I get two
> elements, one containing "This" and the other containing
> "is a comment.".
>
> That seems ... crazy to me. I'm sure I can just change:
>
> #set($comments = $parameterParser.getStrings('comment'))
> to
> #set($comments = $request.getParameterValues('comment'))
>
> ... but I figured that ParameterParser would do the same thing, no?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJZm4ISAAoJEBzwKT+lPKRYKnUP+wQ0ZrGhe4R5X2tCi2nmrzJW
> mgb1fqmBOd5m7TPz9iJnfj6jtLlK2u2u0cPp3BHsFyu8Y4RX5heC1RZ6fJfOPFx1
> Tq5t3JXDoK0XmOL7/VI7R5eadQww9LDbdwR10Gl7Qch9IAfsgYNINIgZwGC1OawD
> kXTc6m8lwKlvBnI7biyncDVY3pOoojh7EQNI6/sh1/hR2n2R35Fa9mpK7Y0Tjk/K
> VkvhqLcuTqii3zlGTBTS0Zzn9XE5+jzFn7wNWmrdbmMYMKKyQCne7gvzH5j3RnK+
> S9jAO/WVazKp2qI7xcAqg1upjqVfP9Rtg/cZOf0hR3swbe5+kJJcP2uw7YEDPGI0
> orFGiIVRTI8+d1FwD4rsn6uoke43p/UVm/2McCkXTkWrvcZ29BLIyin6W+i4/Z6D
> iDciX12YPD/abFsGqMEgAw4CG6WkvlZQnsAtQAtHW5EiDR4DpQQsjeYWxCE+O6SH
> r0lUhGxzed9vBR1M4l5DbnbXRaLJ+kjjZRuDPDLlfXIisD9szdgGOOG8r1dWggaa
> yZXGD/jN6MdnGp12xx7x53+RNqwAPx6o3SJqhJFUxHmOmShIOesoGdv/OsHQk4ep
> tnnlJ8c7bE8oRsH4nT3VxSymY0GCIJFzWvUr2/2lw2wSHW6Om5JoampBamerhmdk
> Lcqksts97wZmYrx+idl4
> =w9Ic
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
> For additional commands, e-mail: user-h...@velocity.apache.org
>
>
Re: [tools 2.0] ValueParser.getStrings splits on comma?
Strangely, I've never hit this one before, but yes, the ValueParser does
consider that values can be string lists, with the coma as the default
string delimiter.
I guess it can be useful in some contexts, but I'm not sure that someone
parsing one's form results would expect this behavior where the presence
of a coma in some string is user-dependant.
The tools configuration does rely on this behavior (so that you can have
), but it could use a
specifically configured instance to do so. So we can change or inhibit
the default string separator.
Claude
On 22/08/2017 03:00, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
I'm not sure if I've used ValueParser.getStrings before (really,
ParameterParser.getStrings, in this case), but I'm surprised by what
is happening. Is this expected?
Request POST parameters:
foo=bar&comment=This, is a comment.
Velocity template code:
#set($comments = $parameterParser.getStrings('comment'))
#if(0 < $comments.size())
#foreach($comment in $comments)
#htmlEscape($comment)
#end## foreach
#end## if(comments)
I would expect this to produce a single element with the
text "This, is a comment." in the text area. Instead, I get two
elements, one containing "This" and the other containing
"is a comment.".
That seems ... crazy to me. I'm sure I can just change:
#set($comments = $parameterParser.getStrings('comment'))
to
#set($comments = $request.getParameterValues('comment'))
... but I figured that ParameterParser would do the same thing, no?
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJZm4ISAAoJEBzwKT+lPKRYKnUP+wQ0ZrGhe4R5X2tCi2nmrzJW
mgb1fqmBOd5m7TPz9iJnfj6jtLlK2u2u0cPp3BHsFyu8Y4RX5heC1RZ6fJfOPFx1
Tq5t3JXDoK0XmOL7/VI7R5eadQww9LDbdwR10Gl7Qch9IAfsgYNINIgZwGC1OawD
kXTc6m8lwKlvBnI7biyncDVY3pOoojh7EQNI6/sh1/hR2n2R35Fa9mpK7Y0Tjk/K
VkvhqLcuTqii3zlGTBTS0Zzn9XE5+jzFn7wNWmrdbmMYMKKyQCne7gvzH5j3RnK+
S9jAO/WVazKp2qI7xcAqg1upjqVfP9Rtg/cZOf0hR3swbe5+kJJcP2uw7YEDPGI0
orFGiIVRTI8+d1FwD4rsn6uoke43p/UVm/2McCkXTkWrvcZ29BLIyin6W+i4/Z6D
iDciX12YPD/abFsGqMEgAw4CG6WkvlZQnsAtQAtHW5EiDR4DpQQsjeYWxCE+O6SH
r0lUhGxzed9vBR1M4l5DbnbXRaLJ+kjjZRuDPDLlfXIisD9szdgGOOG8r1dWggaa
yZXGD/jN6MdnGp12xx7x53+RNqwAPx6o3SJqhJFUxHmOmShIOesoGdv/OsHQk4ep
tnnlJ8c7bE8oRsH4nT3VxSymY0GCIJFzWvUr2/2lw2wSHW6Om5JoampBamerhmdk
Lcqksts97wZmYrx+idl4
=w9Ic
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
Re: [tools 2.0] ValueParser.getStrings splits on comma?
Nathan,
(Apologies for the late reply.)
On 8/22/17 10:58 AM, Nathan Bubna wrote:
> Yeah, that's not ideal. You can configure the string delimiter in your tool
> config. But this seems like surprising behavior for a ParameterTool to
> have. The dangers of inheritance, i think. ConversionTool and ValueParser
> are both built with formats in mind where it makes sense to watch for
> delimited lists. ParameterTool works with inputs where lists have multiple
> entries of the same key, instead of delimited values for a single entry. It
> is convenient to share the interface and conversion code, but we should
> probably change ParameterTool to act as expected by default.
>
> Care to open an issue for this? Or maybe even patch it? :) I may have time
> this week, but can't be sure.
So... just change the default delimiter to ... something like a NUL
(0x00) character? Or maybe RS (Record Separator) 0x1e?
Does anyone have any preference?
Also, what's the best way to make this backward-compatible?
-chris
> On Mon, Aug 21, 2017 at 6:00 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> All,
>
> I'm not sure if I've used ValueParser.getStrings before (really,
> ParameterParser.getStrings, in this case), but I'm surprised by what
> is happening. Is this expected?
>
> Request POST parameters:
> foo=bar&comment=This, is a comment.
>
> Velocity template code:
>
> #set($comments = $parameterParser.getStrings('comment'))
> #if(0 < $comments.size())
> #foreach($comment in $comments)
>
> placeholder="$msg.label.optional_comments">#htmlEscape($comment) ea>
>
> #end## foreach
> #end## if(comments)
>
> I would expect this to produce a single element with the
> text "This, is a comment." in the text area. Instead, I get two
> elements, one containing "This" and the other containing
> "is a comment.".
>
> That seems ... crazy to me. I'm sure I can just change:
>
> #set($comments = $parameterParser.getStrings('comment'))
> to
> #set($comments = $request.getParameterValues('comment'))
>
> ... but I figured that ParameterParser would do the same thing, no?
>
> -chris
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>> For additional commands, e-mail: user-h...@velocity.apache.org
>>
>>
>
signature.asc
Description: OpenPGP digital signature
Re: [tools 2.0] ValueParser.getStrings splits on comma?
Chris, after you raised this issue I commited a fix in the tools trunk, see
http://svn.apache.org/viewvc?view=revision&revision=1806598
It sets the default delimiter to the empty string in the default
tools.xml for the ParameterParser and fixes the code so that it does
work. It's backward compatible since the empty string wasn't functional
before. Sorry I didn't react on the list.
Claude
On 14/10/2017 16:18, Christopher Schultz wrote:
Nathan,
(Apologies for the late reply.)
On 8/22/17 10:58 AM, Nathan Bubna wrote:
Yeah, that's not ideal. You can configure the string delimiter in your tool
config. But this seems like surprising behavior for a ParameterTool to
have. The dangers of inheritance, i think. ConversionTool and ValueParser
are both built with formats in mind where it makes sense to watch for
delimited lists. ParameterTool works with inputs where lists have multiple
entries of the same key, instead of delimited values for a single entry. It
is convenient to share the interface and conversion code, but we should
probably change ParameterTool to act as expected by default.
Care to open an issue for this? Or maybe even patch it? :) I may have time
this week, but can't be sure.
So... just change the default delimiter to ... something like a NUL
(0x00) character? Or maybe RS (Record Separator) 0x1e?
Does anyone have any preference?
Also, what's the best way to make this backward-compatible?
-chris
On Mon, Aug 21, 2017 at 6:00 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
All,
I'm not sure if I've used ValueParser.getStrings before (really,
ParameterParser.getStrings, in this case), but I'm surprised by what
is happening. Is this expected?
Request POST parameters:
foo=bar&comment=This, is a comment.
Velocity template code:
#set($comments = $parameterParser.getStrings('comment'))
#if(0 < $comments.size())
#foreach($comment in $comments)
#htmlEscape($comment)
#end## foreach
#end## if(comments)
I would expect this to produce a single element with the
text "This, is a comment." in the text area. Instead, I get two
elements, one containing "This" and the other containing
"is a comment.".
That seems ... crazy to me. I'm sure I can just change:
#set($comments = $parameterParser.getStrings('comment'))
to
#set($comments = $request.getParameterValues('comment'))
... but I figured that ParameterParser would do the same thing, no?
-chris
-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
Re: [tools 2.0] ValueParser.getStrings splits on comma?
Claude,
On 10/14/17 6:16 PM, Claude Brisson wrote:
> Chris, after you raised this issue I commited a fix in the tools trunk, see
>
> http://svn.apache.org/viewvc?view=revision&revision=1806598
>
> It sets the default delimiter to the empty string in the default
> tools.xml for the ParameterParser and fixes the code so that it does
> work. It's backward compatible since the empty string wasn't functional
> before. Sorry I didn't react on the list.
I think this may be a problem, though, since many may rely on the
previous-default which was "," and now the default is "".
Unfortunately, I think you should probably go back to comma as default,
unless this is expected to be for a major velocity-tools release.
Thanks,
-chris
> On 14/10/2017 16:18, Christopher Schultz wrote:
>> Nathan,
>>
>> (Apologies for the late reply.)
>>
>> On 8/22/17 10:58 AM, Nathan Bubna wrote:
>>> Yeah, that's not ideal. You can configure the string delimiter in
>>> your tool
>>> config. But this seems like surprising behavior for a ParameterTool to
>>> have. The dangers of inheritance, i think. ConversionTool and
>>> ValueParser
>>> are both built with formats in mind where it makes sense to watch for
>>> delimited lists. ParameterTool works with inputs where lists have
>>> multiple
>>> entries of the same key, instead of delimited values for a single
>>> entry. It
>>> is convenient to share the interface and conversion code, but we should
>>> probably change ParameterTool to act as expected by default.
>>>
>>> Care to open an issue for this? Or maybe even patch it? :) I may have
>>> time
>>> this week, but can't be sure.
>> So... just change the default delimiter to ... something like a NUL
>> (0x00) character? Or maybe RS (Record Separator) 0x1e?
>>
>> Does anyone have any preference?
>>
>> Also, what's the best way to make this backward-compatible?
>>
>> -chris
>>
>>> On Mon, Aug 21, 2017 at 6:00 PM, Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>>
>>> All,
>>>
>>> I'm not sure if I've used ValueParser.getStrings before (really,
>>> ParameterParser.getStrings, in this case), but I'm surprised by what
>>> is happening. Is this expected?
>>>
>>> Request POST parameters:
>>> foo=bar&comment=This, is a comment.
>>>
>>> Velocity template code:
>>>
>>> #set($comments = $parameterParser.getStrings('comment'))
>>> #if(0 < $comments.size())
>>> #foreach($comment in $comments)
>>>
>>> >> placeholder="$msg.label.optional_comments">#htmlEscape($comment)>> ea>
>>>
>>> #end## foreach
>>> #end## if(comments)
>>>
>>> I would expect this to produce a single element with the
>>> text "This, is a comment." in the text area. Instead, I get two
>>> elements, one containing "This" and the other containing
>>> "is a comment.".
>>>
>>> That seems ... crazy to me. I'm sure I can just change:
>>>
>>> #set($comments = $parameterParser.getStrings('comment'))
>>> to
>>> #set($comments = $request.getParameterValues('comment'))
>>>
>>> ... but I figured that ParameterParser would do the same thing, no?
>>>
>>> -chris
-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
> For additional commands, e-mail: user-h...@velocity.apache.org
>
signature.asc
Description: OpenPGP digital signature
Re: [tools 2.0] ValueParser.getStrings splits on comma?
On 30/10/2017 17:25, Christopher Schultz wrote:
Claude,
On 10/14/17 6:16 PM, Claude Brisson wrote:
Chris, after you raised this issue I commited a fix in the tools trunk, see
http://svn.apache.org/viewvc?view=revision&revision=1806598
It sets the default delimiter to the empty string in the default
tools.xml for the ParameterParser and fixes the code so that it does
work. It's backward compatible since the empty string wasn't functional
before. Sorry I didn't react on the list.
I think this may be a problem, though, since many may rely on the
previous-default which was "," and now the default is "".
The default is still ',' for the non HTTP ValueVarser tool.
Since the ParameterParser is *meant* for HTTP, the default was
previously wrong, not only because HTTP uses key repetition but also, as
you discovered, because it splits values containing comas.
Since were releasing a major version, I think it's more reasonable to
change it, while making it sure that we mention this point in the
upgrading notes. Users willing to keep the former behavior will just
have to set back the coma as separator in their tools.xml.
Claude
Unfortunately, I think you should probably go back to comma as default,
unless this is expected to be for a major velocity-tools release.
Thanks,
-chris
On 14/10/2017 16:18, Christopher Schultz wrote:
Nathan,
(Apologies for the late reply.)
On 8/22/17 10:58 AM, Nathan Bubna wrote:
Yeah, that's not ideal. You can configure the string delimiter in
your tool
config. But this seems like surprising behavior for a ParameterTool to
have. The dangers of inheritance, i think. ConversionTool and
ValueParser
are both built with formats in mind where it makes sense to watch for
delimited lists. ParameterTool works with inputs where lists have
multiple
entries of the same key, instead of delimited values for a single
entry. It
is convenient to share the interface and conversion code, but we should
probably change ParameterTool to act as expected by default.
Care to open an issue for this? Or maybe even patch it? :) I may have
time
this week, but can't be sure.
So... just change the default delimiter to ... something like a NUL
(0x00) character? Or maybe RS (Record Separator) 0x1e?
Does anyone have any preference?
Also, what's the best way to make this backward-compatible?
-chris
On Mon, Aug 21, 2017 at 6:00 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
All,
I'm not sure if I've used ValueParser.getStrings before (really,
ParameterParser.getStrings, in this case), but I'm surprised by what
is happening. Is this expected?
Request POST parameters:
foo=bar&comment=This, is a comment.
Velocity template code:
#set($comments = $parameterParser.getStrings('comment'))
#if(0 < $comments.size())
#foreach($comment in $comments)
#htmlEscape($comment)
#end## foreach
#end## if(comments)
I would expect this to produce a single element with the
text "This, is a comment." in the text area. Instead, I get two
elements, one containing "This" and the other containing
"is a comment.".
That seems ... crazy to me. I'm sure I can just change:
#set($comments = $parameterParser.getStrings('comment'))
to
#set($comments = $request.getParameterValues('comment'))
... but I figured that ParameterParser would do the same thing, no?
-chris
-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
Re: [tools 2.0] ValueParser.getStrings splits on comma?
Claude, On 10/30/17 12:47 PM, Claude Brisson wrote: > > > On 30/10/2017 17:25, Christopher Schultz wrote: >> Claude, >> >> On 10/14/17 6:16 PM, Claude Brisson wrote: >>> Chris, after you raised this issue I commited a fix in the tools >>> trunk, see >>> >>> http://svn.apache.org/viewvc?view=revision&revision=1806598 >>> >>> It sets the default delimiter to the empty string in the default >>> tools.xml for the ParameterParser and fixes the code so that it does >>> work. It's backward compatible since the empty string wasn't functional >>> before. Sorry I didn't react on the list. >> I think this may be a problem, though, since many may rely on the >> previous-default which was "," and now the default is "". > > The default is still ',' for the non HTTP ValueVarser tool. > > Since the ParameterParser is *meant* for HTTP, the default was > previously wrong, not only because HTTP uses key repetition but also, as > you discovered, because it splits values containing comas. > > Since were releasing a major version, I think it's more reasonable to > change it, while making it sure that we mention this point in the > upgrading notes. Users willing to keep the former behavior will just > have to set back the coma as separator in their tools.xml. +1 The major version makes all the difference, even if the previous default was very inappropriate. (Wearing my Bill Rowe hat right now ;) Thanks, -chris signature.asc Description: OpenPGP digital signature
