[
https://issues.apache.org/jira/browse/WICKET-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555977#comment-13555977
]
Martin Grigorov commented on WICKET-4972:
-----------------------------------------
I think the best is to make defaultValue's type IModel<String> and use Object[]
for the parameters.
I don't see a way to fix/improve this without API break. It seems it has to
wait for Wicket 7.
> Remove (or disarm) varargs contructors of StringResourceModel (more of a
> pitfall than convenience)
> --------------------------------------------------------------------------------------------------
>
> Key: WICKET-4972
> URL: https://issues.apache.org/jira/browse/WICKET-4972
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 6.4.0
> Reporter: Peter Parson
>
> The introduction of varargs constructors for StringResourceModel also
> introduced a pitfall which (IMO) outweighs the convenience of not explicitely
> having to create an array.
> When using this constructor:
> public StringResourceModel(final String resourceKey, final Component
> component, final IModel<?> model, final Object... parameters)
> one runs into problems when parameters are of type String (which probably
> happens more often than not), since the VM acutally ends up calling
> public StringResourceModel(final String resourceKey, final Component
> component, final IModel<?> model, final String defaultValue, final Object...
> parameters)
> From my experience, this happens repeatedly to Wicket newbies, but still to
> "veterans" sometimes.
> Example (does not work as one would expect):
> new StringResourceModel("my.resource.key", this, getModel(), "first param to
> replace", "second param to replace");
> Forcing to do either
> new StringResourceModel("my.resource.key", this, getModel(), null, "first
> param to replace", "second param to replace");
> or
> new StringResourceModel("my.resource.key", this, getModel(),
> newObject[]{"first param to replace", "second param to replace"});
> I think varargs is a convenient feature, but in this special case it
> introduces confusion, outweighing the convenience by far, thus I suggest to
> expect explicit array like before.
> Another solution might be to expect a Model<String> as defaultValue or to
> change the order of constructor arguments.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
