[
https://issues.apache.org/jira/browse/VELTOOLS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540157
]
Claude Brisson commented on VELTOOLS-69:
----------------------------------------
> Claude Brisson wrote:
>> Thinking back about it, wouldn't it be possible for the parser to split
>> those keys that contain periods and to allocate new hashmaps to their first
>> key part?
>> That is, if we have a form field name "foo.bar", then $query.foo would be a
>> hashmap containing a 'bar' key.
Nathan Bubna wrote:
> When would this splitting be done? I wouldn't want to do it all up front, as
> that seems like it could affect performance.
> I suppose if "foo" is requested and has no value, then we could search the
> value map for things starting with "foo.", if any are found, then convert
> those to a hashmap and return it. But that seems like it would still break
> #if($query.foo) so far as backwards compatibility goes. Maybe we can do
> something like this (with either a "sub" or a hashmap) in VelocityTools 2.0,
> but i don't want to break B.C. for this version.
What about considering this feature for 2.0? Since I've coded it for Velosurf
I can handle it.
Claude
> ValueParserSub generic getter never worked
> ------------------------------------------
>
> Key: VELTOOLS-69
> URL: https://issues.apache.org/jira/browse/VELTOOLS-69
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
> Affects Versions: 1.3
> Reporter: Claude Brisson
> Fix For: 1.3
>
> Attachments: valueparser.patch
>
>
> (I attach this issue to the VelocityView component but we may need a Generic
> component in Jira)
> When $query is the ValueParser object for the query string http://...?foo=5,
> then $query.foo.int is an invalid reference.
> Why? Because there is a collision of variable names in
> ValueParserSub.get(Object key).
> I profit of this opportunity to state that I really don't like the
> ValueParserSub class, because it breaks the "#if($query.foo)" syntax. Hence,
> it is not backward compatible. Or at least, it could return null for an
> unexistant key.
> Is it really usefull to keep it now that Velocity handles conversions much
> better? Since obviously nobody used the $query.foo.int feature, it is still
> time to remove it... Also, since the need to convert between types can emerge
> elsewhere, it would be much cleaner to have a standalone converter object.
> Yes, we loose the syntax $query.foo.int, but is it that nice a syntax?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
