[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654872#comment-16654872 ] Thomas Mortagne commented on VELOCITY-892: -- > And you can give Velocity the former (now deprecated in the branch) > ConversionHandler or the new one in the runtime.conversion.handler.class > property. Is there any alternative programmatic way to pass a Java instance instead ? Otherwise I will have to store some stuff in a static for the XWikiTypeConversionHandler constructor to access it when it's called by Velocity. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654073#comment-16654073
]
Claude Brisson commented on VELOCITY-892:
-
The reenginering provides both, with the new {{TypeConversionHandler}} :
{code:java}
public interface TypeConversionHandler
{
boolean isExplicitlyConvertible(Type formal, Class actual, boolean
possibleVarArg);
Converter getNeededConverter(Type formal, Class actual);
void addConverter(Type formal, Class actual, Converter converter);
}
{code}
> Method arguments conversions should be based on Type instead of Class
> -
>
> Key: VELOCITY-892
> URL: https://issues.apache.org/jira/browse/VELOCITY-892
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Thomas Mortagne
>Priority: Major
> Fix For: 2.0
>
>
> I was happy to see that method arguments conversion has been added to 2.0 so
> that I can remove the uberspector we have on XWiki side but unfortunately
> ConversionHandler is limited to classes which is way too restrictive for us
> (for example if the parameter type is List it won't do the same thing
> than if the type is List).
> Our uberspector can be found on
> https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java
> to see what we do exactly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654029#comment-16654029 ] Thomas Mortagne commented on VELOCITY-892: -- bq. Well, to my mind, whether Velocity is Type-aware I never suggested that Velocity should not be Type aware. I'm just saying that there is two different levels: * provider a custom converter handler * provider custom converters to the default converter handler > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653806#comment-16653806 ] Claude Brisson commented on VELOCITY-892: - Well, to my mind, whether Velocity is Type-aware, whether it's not. Any in-between solution where a Type replaces a Class in an interface just to leave an open door to potential implementors is rather problematic. What would the standard implementation do when it receives a Type which isn't a Class? > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653786#comment-16653786 ] Thomas Mortagne commented on VELOCITY-892: -- Actually my plan was to implement a ConversionHandler and not add a set of converters since XWiki already have a conversion system which is used in https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java for example. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653755#comment-16653755
]
Claude Brisson commented on VELOCITY-892:
-
The VELOCITY-892 branch is ready to be tested (and it wasn't that easy).
*But*.
At some point, to register your custom converter, you'll have to call
{{addConverter(Type, Class, Converter)}}
and how you will specify List for the Type parameter is unclear. For
instance, you can do
{{TypeUtils.parameterize(List.class, String.class)}}
from commons-lang3, or use reflection methods on some custom object.
And inside the conversion handling of Velocity, at some point, I have to
*compare* two instances of Type. And I'm not meaning a comparison using
{{equals()}}, which would work, but since I have to *index* the types in a Map,
I need to rely on an {{hashCode()}} equality. And for instance the hash code
returned by the commons-lang3 ParameterizedType has nothing to do with Sun hash
codes for internal ParameterizedType implementations.
Hence, I have to rely on the {{Type.getTypeName()}} method to index types on
their names, which doesn't exist in Java 7. So merging this branch would
require to raise the javac language target to 1.8.
> Method arguments conversions should be based on Type instead of Class
> -
>
> Key: VELOCITY-892
> URL: https://issues.apache.org/jira/browse/VELOCITY-892
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Thomas Mortagne
>Priority: Major
> Fix For: 2.0
>
>
> I was happy to see that method arguments conversion has been added to 2.0 so
> that I can remove the uberspector we have on XWiki side but unfortunately
> ConversionHandler is limited to classes which is way too restrictive for us
> (for example if the parameter type is List it won't do the same thing
> than if the type is List).
> Our uberspector can be found on
> https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java
> to see what we do exactly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653288#comment-16653288 ] Claude Brisson commented on VELOCITY-892: - Ok. I'm going to try to go the BC way anyway, that's more work but let's be strict about the versionning policy. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653144#comment-16653144 ] Michael Osipov commented on VELOCITY-892: - I'd really like a branch on this first before anything is merged back to trunk. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653111#comment-16653111 ] Thomas Mortagne commented on VELOCITY-892: -- bq. because it's painful to have the API evolve Yeah always a pain. One possibility I guess is having two kind of converters and call one after the other but yes never nice to have to support the one you don't want people to use anymore. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16652601#comment-16652601 ] Claude Brisson commented on VELOCITY-892: - I'm not saying that it's complex, neither that it isn't a better design choice. I just wanted to check that it was worth, because it's painful to have the API evolve. Unless we decide to break backward compatibility on the ConversionHandler API. Keeping BC would mean having a default implementation in the interface for the new method, and dragging the deprecated one along up to 3.0... so I'm more inclined to drop BC in this specific case, it should rigorously be a 3.0 but Velocity 2.0 hasn't been out for very long and it's quite a minor change. If no one chimes in, that's what I'll do. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16651842#comment-16651842 ] Thomas Mortagne commented on VELOCITY-892: -- bq. Basically, you need to be able to define several converters, String -> List, String -> List , String -> List, ... Yes. bq. Would any of the proposed workarounds fit your case? Otherwise, may I ask, is this feature used a lot? Type with generics are used a lot in input in XWiki yes. bq. Basically, I'm not even sure that this conversion does deserve to be implicit. After all, the separator can vary, there can be beginning and ending normal/square/curly brackets, or other parsing issue... I gave List as an example because it's well know type but it's the same for many other types. bq. Would any of the proposed workarounds fit your case? Otherwise, may I ask, is this feature used a lot? No because we have this feature since a long time and it's used already. Having Type instead of Class in the API does not make much difference for Velocity and give more power to the converter so I don't really see what is the issue exactly. It's really not a blocker since it's not like it was super hard to maintain our uberspector but it's a pity to not have a better API at Velocity level. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16651733#comment-16651733
]
Michael Osipov commented on VELOCITY-892:
-
Can't the callee simply provide an overload with {{String}} arg which does the
splitting?
> Method arguments conversions should be based on Type instead of Class
> -
>
> Key: VELOCITY-892
> URL: https://issues.apache.org/jira/browse/VELOCITY-892
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Thomas Mortagne
>Priority: Major
> Fix For: 2.0
>
>
> I was happy to see that method arguments conversion has been added to 2.0 so
> that I can remove the uberspector we have on XWiki side but unfortunately
> ConversionHandler is limited to classes which is way too restrictive for us
> (for example if the parameter type is List it won't do the same thing
> than if the type is List).
> Our uberspector can be found on
> https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java
> to see what we do exactly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16651716#comment-16651716
]
Claude Brisson commented on VELOCITY-892:
-
Ok, I understand.
Basically, you need to be able to define several converters, String ->
List, String -> List , String -> List, ...
I don't really think of any other use case, because since you cannot have the
parameterized types of the input argument. Also, the class containing the
method will only have *one* such method. So if you *already* know the target
class, you can register the proper converter.
Or, the target class can accept a List and handle the conversion.
Or, you can provide the template writer a tool with a {{toIntegerList()}}
method.
Would any of the proposed workarounds fit your case? Otherwise, may I ask, is
this feature used a lot?
Basically, I'm not even sure that this conversion does deserve to be implicit.
After all, the separator can vary, there can be beginning and ending
normal/square/curly brackets, or other parsing issue...
> Method arguments conversions should be based on Type instead of Class
> -
>
> Key: VELOCITY-892
> URL: https://issues.apache.org/jira/browse/VELOCITY-892
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Thomas Mortagne
>Priority: Major
> Fix For: 2.0
>
>
> I was happy to see that method arguments conversion has been added to 2.0 so
> that I can remove the uberspector we have on XWiki side but unfortunately
> ConversionHandler is limited to classes which is way too restrictive for us
> (for example if the parameter type is List it won't do the same thing
> than if the type is List).
> Our uberspector can be found on
> https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java
> to see what we do exactly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650084#comment-16650084
]
Thomas Mortagne commented on VELOCITY-892:
--
I'm not really talking about having two methods in the same class but simply
having methods taking something else than List or List as parameter.
Imagine the following use case:
{quote}
public void foo(List parameter)
{
for (Integer value : parameter) {
// do stuff with the integer
}
}
{quote}
{quote}
$obj.foo("1, 2, 3, 4, 5")
{quote}
It's impossible for the converter to know it should convert each element of the
list to Integer so at best you will write a converter which produce a
List and the method will crash with a ClassCastException.
> Method arguments conversions should be based on Type instead of Class
> -
>
> Key: VELOCITY-892
> URL: https://issues.apache.org/jira/browse/VELOCITY-892
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Thomas Mortagne
>Priority: Major
> Fix For: 2.0
>
>
> I was happy to see that method arguments conversion has been added to 2.0 so
> that I can remove the uberspector we have on XWiki side but unfortunately
> ConversionHandler is limited to classes which is way too restrictive for us
> (for example if the parameter type is List it won't do the same thing
> than if the type is List).
> Our uberspector can be found on
> https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java
> to see what we do exactly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650046#comment-16650046
]
Claude Brisson commented on VELOCITY-892:
-
{quote}for example if the parameter type is List it won't do the same
thing than if the type is List
{quote}
Since it's invalid in Java to have two methods with the same name and same
argument type *after* type erasure, this use case doesn't stand, does it? Or
can you be more explicit?
And if you have other typical use cases in mind where Velocity doesn't have the
proper behavior, can you share them?
> Method arguments conversions should be based on Type instead of Class
> -
>
> Key: VELOCITY-892
> URL: https://issues.apache.org/jira/browse/VELOCITY-892
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Thomas Mortagne
>Priority: Major
> Fix For: 2.0
>
>
> I was happy to see that method arguments conversion has been added to 2.0 so
> that I can remove the uberspector we have on XWiki side but unfortunately
> ConversionHandler is limited to classes which is way too restrictive for us
> (for example if the parameter type is List it won't do the same thing
> than if the type is List).
> Our uberspector can be found on
> https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java
> to see what we do exactly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
