You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Claude Brisson (JIRA)" <ve...@apache.org> on 2006/11/15 10:33:42 UTC
[jira] Created: (VELTOOLS-69) ValueParserSub generic getter never
worked
ValueParserSub generic getter never worked
------------------------------------------
Key: VELTOOLS-69
URL: http://issues.apache.org/jira/browse/VELTOOLS-69
Project: VelocityTools
Issue Type: Bug
Components: VelocityView
Affects Versions: 1.3
Reporter: Claude Brisson
(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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Claude Brisson (JIRA)" <ve...@apache.org>.
[ http://issues.apache.org/jira/browse/VELTOOLS-69?page=comments#action_12450152 ]
Claude Brisson commented on VELTOOLS-69:
----------------------------------------
But isn't the conversion of native datatypes a task dedicated to velocity itself, at the time the reference is used in a comparison or as an argument? It seems to me that the need for $query.foo.int/number/boolean/double... becomes quite marginal with conversions built in velocity 1.5, and that in those rare cases where you absolutely need an exact type you can call $query.getInt("foo").
As for the case of a period inside the key, IMHO it shoud go into the core. There are numerous other cases where it could be useful.
> ValueParserSub generic getter never worked
> ------------------------------------------
>
> Key: VELTOOLS-69
> URL: http://issues.apache.org/jira/browse/VELTOOLS-69
> Project: VelocityTools
> Issue Type: Bug
> Components: VelocityView
> Affects Versions: 1.3
> Reporter: Claude Brisson
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Will Glass-Husain (JIRA)" <ve...@apache.org>.
[ http://issues.apache.org/jira/browse/VELTOOLS-69?page=comments#action_12450176 ]
Will Glass-Husain commented on VELTOOLS-69:
-------------------------------------------
Not being a tools user, I'm not following the core-related suggestion. Can someone raise an issue under "Velocity" and explain the proposed syntax/behavior change?
> ValueParserSub generic getter never worked
> ------------------------------------------
>
> Key: VELTOOLS-69
> URL: http://issues.apache.org/jira/browse/VELTOOLS-69
> Project: VelocityTools
> Issue Type: Bug
> Components: VelocityView
> Affects Versions: 1.3
> Reporter: Claude Brisson
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Nathan Bubna (JIRA)" <ve...@apache.org>.
[ http://issues.apache.org/jira/browse/VELTOOLS-69?page=comments#action_12450204 ]
Nathan Bubna commented on VELTOOLS-69:
--------------------------------------
Velocity doesn't actually convert references to anything but strings, and it is only in 1.5 that the rendered string values are used in comparisons when the types of the arguments do not match. As for method arguments, Velocity only converts primitives to Objects and vice versa.
So, no, conversion of native datatypes is not something Velocity does much of for you. Of course, i don't recommend heavy use of in-template conversion, but nonetheless, they are sometimes necessary and are thus necessarily supported by generic tools, especially the ValueParser, which was designed for precisely and almost exclusively that purpose.
Allowing periods in keys in the Velocity engine would have quite a few implications, and i'm not sure how difficult it would be to implement (or at least, to implement consistently. Something to think about though...
Anyway, i've poked around the Velocity internals and tried a few things, but i don't think i can get the sub working without losing backward compatibility in at least a few cases. So, it needs to come out for 1.3.
Thanks for bringing this up!
> ValueParserSub generic getter never worked
> ------------------------------------------
>
> Key: VELTOOLS-69
> URL: http://issues.apache.org/jira/browse/VELTOOLS-69
> Project: VelocityTools
> Issue Type: Bug
> Components: VelocityView
> Affects Versions: 1.3
> Reporter: Claude Brisson
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Nathan Bubna (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELTOOLS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540270 ]
Nathan Bubna commented on VELTOOLS-69:
--------------------------------------
I'm definitely open to it. Though i find myself still reluctant to break #if( $query.foo ) given all the effort i've put into BC elsewhere in 2.0. If we do this, then we should make ValueParser pick up the deprecationSupportMode property and only implement this behavior when that is false. This would at least ensure that #if( $query.foo ) works for anyone who is using the old toolbox.xml format or explicitly sets deprecationSupportMode to true for that tool.
Are you interested in tackling the re-implementation of this? If not, i could probably make some time in the next week or so.
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Claude Brisson (JIRA)" <ve...@apache.org>.
[ http://issues.apache.org/jira/browse/VELTOOLS-69?page=comments#action_12453918 ]
Claude Brisson commented on VELTOOLS-69:
----------------------------------------
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.
This method seems much cleaner than the patch I submitted to the core.
> ValueParserSub generic getter never worked
> ------------------------------------------
>
> Key: VELTOOLS-69
> URL: http://issues.apache.org/jira/browse/VELTOOLS-69
> Project: VelocityTools
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Claude Brisson (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELTOOLS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540435 ]
Claude Brisson commented on VELTOOLS-69:
----------------------------------------
I have some time to work on it, so let's say I take care of it.
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Resolved: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Nathan Bubna (JIRA)" <ve...@apache.org>.
[ http://issues.apache.org/jira/browse/VELTOOLS-69?page=all ]
Nathan Bubna resolved VELTOOLS-69.
----------------------------------
Fix Version/s: 1.3
Resolution: Fixed
Ok, the sub is gone as of revision 475480.
> ValueParserSub generic getter never worked
> ------------------------------------------
>
> Key: VELTOOLS-69
> URL: http://issues.apache.org/jira/browse/VELTOOLS-69
> Project: VelocityTools
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Updated: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Claude Brisson (JIRA)" <ve...@apache.org>.
[ http://issues.apache.org/jira/browse/VELTOOLS-69?page=all ]
Claude Brisson updated VELTOOLS-69:
-----------------------------------
Attachment: valueparser.patch
My proposed patch that removes ValueParserSub.
> ValueParserSub generic getter never worked
> ------------------------------------------
>
> Key: VELTOOLS-69
> URL: http://issues.apache.org/jira/browse/VELTOOLS-69
> Project: VelocityTools
> Issue Type: Bug
> Components: VelocityView
> Affects Versions: 1.3
> Reporter: Claude Brisson
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Nathan Bubna (JIRA)" <ve...@apache.org>.
[ http://issues.apache.org/jira/browse/VELTOOLS-69?page=comments#action_12454002 ]
Nathan Bubna commented on VELTOOLS-69:
--------------------------------------
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.
> ValueParserSub generic getter never worked
> ------------------------------------------
>
> Key: VELTOOLS-69
> URL: http://issues.apache.org/jira/browse/VELTOOLS-69
> Project: VelocityTools
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Nathan Bubna (JIRA)" <ve...@apache.org>.
[ http://issues.apache.org/jira/browse/VELTOOLS-69?page=comments#action_12450118 ]
Nathan Bubna commented on VELTOOLS-69:
--------------------------------------
Hmm. Breaking #if($query.foo) compatibility isn't ok, if we can't find a reasonable way to keep that and the sub, then i'll ditch the sub. But i much prefer $query.foo.bar over $query.get('foo.bar'), so i'm not going to give that up quickly. The type conversion suffixes are more than just nice since the main point of the ValueParser is to parse values. If you don't care about type conversion, then you may as well just put the source map into the context.
Anyway, i'm going to see if i can make both work somehow. If i can't, then expect me to resurrect the sub in a later version where complete backwards compatibility isn't necessary.
> ValueParserSub generic getter never worked
> ------------------------------------------
>
> Key: VELTOOLS-69
> URL: http://issues.apache.org/jira/browse/VELTOOLS-69
> Project: VelocityTools
> Issue Type: Bug
> Components: VelocityView
> Affects Versions: 1.3
> Reporter: Claude Brisson
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Claude Brisson (JIRA)" <ve...@apache.org>.
[ http://issues.apache.org/jira/browse/VELTOOLS-69?page=comments#action_12450185 ]
Claude Brisson commented on VELTOOLS-69:
----------------------------------------
I didn't double-check in the sources if it doesn't already exist in the engine, but I don't think so.
The idea is that for a reference $a.b.c, if the engine finds out that $a.b is null, it should also check $a.get("b.c") - that is, to allow periods in secondary key names.
> ValueParserSub generic getter never worked
> ------------------------------------------
>
> Key: VELTOOLS-69
> URL: http://issues.apache.org/jira/browse/VELTOOLS-69
> Project: VelocityTools
> Issue Type: Bug
> Components: VelocityView
> Affects Versions: 1.3
> Reporter: Claude Brisson
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Claude Brisson (JIRA)" <de...@velocity.apache.org>.
[ 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELTOOLS-69) ValueParserSub generic getter never
worked
Posted by "Claude Brisson (JIRA)" <ve...@apache.org>.
[ http://issues.apache.org/jira/browse/VELTOOLS-69?page=comments#action_12450189 ]
Claude Brisson commented on VELTOOLS-69:
----------------------------------------
I should add that this feature is quite interesting when dealing with $query.form_field where form_field contains periods (something likely to happen in HTML).
> ValueParserSub generic getter never worked
> ------------------------------------------
>
> Key: VELTOOLS-69
> URL: http://issues.apache.org/jira/browse/VELTOOLS-69
> Project: VelocityTools
> Issue Type: Bug
> Components: VelocityView
> Affects Versions: 1.3
> Reporter: Claude Brisson
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org