Thank you! I also think it's a good solution.
On 26/05/2015 14:41, Martijn Dashorst wrote:
Done.
On Tue, May 26, 2015 at 2:39 PM, Martijn Dashorst
<[email protected]> wrote:
OK, then I'll commit and push.
Martijn
On Tue, May 26, 2015 at 2:37 PM, Martin Grigorov <[email protected]> wrote:
This looks handy!
I'm +1 to have it in -core.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, May 26, 2015 at 3:33 PM, Martijn Dashorst <
[email protected]> wrote:
Using this class I was able to migrate our 7 invocations within a
couple of minutes.
Martijn
On Tue, May 26, 2015 at 2:32 PM, Martijn Dashorst
<[email protected]> wrote:
So instead of re-introducing the constructors, we could opt to provide
a utility that makes it easy to refactor code to the new fluent API,
and document its use in the migration guide.
For example:
https://gist.github.com/dashorst/5ae5ebcdedab9da34792
We could create a wicket-migrate-7.x module to add more of these
classes if necessary/useful. But for convenience they should be in
core.
Martijn
On Tue, May 26, 2015 at 2:09 PM, Martijn Dashorst
<[email protected]> wrote:
On Tue, May 26, 2015 at 2:02 PM, Martin Grigorov <[email protected]>
wrote:
By reverting the constructors from 6.x we will reintroduce
https://issues.apache.org/jira/browse/WICKET-4972
In our 1.2M lines of code project, there are only 7 invocations of the
StringResourceModel constructor that I have to figure out, so this is
(for our company at least) a minor issue. I can imagine that
internationalized apps will have a bigger problem.
I don't know how to handle WICKET-4972. The way it was in Wicket 7
broke silently for us, while the situation from Wicket 6.19 and prior
was working.
Martijn
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
