Re: [tools 2.0] ValueParser.getStrings splits on comma?

Christopher Schultz <[email protected]> Mon, 30 Oct 2017 12:25:40 -0400
Newsgroups	gmane.comp.jakarta.velocity.user
Message-ID	<[email protected]>
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 <
>>> [email protected]> 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)
>>>    <div class="comment">
>>>      <textarea name="comment"
>>> placeholder="$msg.label.optional_comments">#htmlEscape($comment)</textar
>>> ea>
>>>    </div>
>>> #end## foreach
>>> #end## if(comments)
>>>
>>> I would expect this to produce a single <textarea> element with the
>>> text "This, is a comment." in the text area. Instead, I get two
>>> <textarea> 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: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
signature.asc (application/pgp-signature, 938 B)