Hi all,
I've pushed a proposal for a replacement of StringResourceModel on
branch WICKET-4972-PropertyResourceModel :
Instead of an parameter array (or varargs) it uses a map of models.
Here is a comparison, first a simple case with a single model only:
* new StringResourceModel("simple", component, fooModel);
simple = This is simply ${}.
* new PropertyResourceModel("simple", component, fooModel);
simple = This is simply ${}.
So no changes here, result is:
"This is simply foo,".
Now the most complicated usage:
* new StringResourceModel("complex.${bar}", component, fooModel,
defaultValue, dateModel, "Wicket", );
complex.bar1=This is complex for ${whom} on {0} with {1}.
* new PropertyResourceModel("complex.${foo.bar}", component,
MiniMap.of("foo", fooModel, "date", dateModel, "lib",
Model.of("Wicket")), defaultValue);
complex.bar1=This is complex for ${foo.whom} on ${date} with ${lib}.
Each model is identified with the prefix it was put into the map. Result is:
"This is complex for him on 9/25/2014 with Wicket."
Advantages:
- no varargs or object-array - and no decision needed between the two ;)
- no foreign indexed-based syntax {0}, improved readability and
maintainability of resources
- all values can use nested property expressions and are converted
using Wicket converters
- simpler code (no need for escaping, one parsing only)
Disadvantages:
- maps are aqward to create in Java :/ ... I've added a few utility
methods to MiniMap though.
Let me know if I missed something or when you don't like this at all.
Have fun
Sven
On 09/24/2014 09:32 AM, Martin Grigorov wrote:
What do you think about marking StringResourceModel as deprecated and
provide a new Model impl with the suggested improvements ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Sep 24, 2014 at 12:44 AM, Sven Meier <[email protected]> wrote:
Hi all,
AFAIKS these extra parameters are needed to support multiple data inputs
only.
Additionally to the var-args vs array decision, I don't like that we are
using MessageFormat for this: it has a foreign syntax {0}, it's index-based
and it doesn't work with Wicket converters.
I'd preferred if we could replace this with something else - so instead of:
new StringResourceModel("weather.detail", page, wsModel,
cal.getTime(), "${currentStatus}", new
PropertyModel<Double>(wsModel,
"currentTemperature"), new PropertyModel<String>(wsModel,
"units"));
The report for {0,date,medium}, shows the temperature as
{2,number,###.##} {3} and the weather to be {1}
... something like the following:
new StringResourceModel("weather.detail", page)
.addModel("station", wsModel)
.addModel("date", Model.of(cal.getTime()));
The report for ${date}, shows the temperature as
${station.currentTemperatur} ${station.units} and the weather to be
${station.currentStatus}
Each nested model is scoped with an identifier and can easily be
identified from the message string.
Sven
On 09/23/2014 02:42 PM, Martin Grigorov wrote:
Hi,
https://issues.apache.org/jira/browse/WICKET-5702 hit a problem with
StringResourceModel that we uses Object... as a last parameter in its
constructors.
I think that using Object... is evil, especially when there is an
overloaded method/constructor that "looks like" the other one.
For example:
MyObject(String p1, Object... extra)
MyObject(String p1, Integer p2, Object... extra)
If a developer wants to pass p2 as an extra then (s)he has to be really
careful.
In https://issues.apache.org/jira/browse/WICKET-4972 I have suggested to
use Object[] instead, but later when I worked on it for 7.0.0-M1 I have
forgotten to change it.
By using Object[] the developer has to type some more but it is much
easier
to reason about.
Any objections to make the change for 7.0.0-M4 ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
