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)
>>> <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: 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
