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 >
