I have been a bit out of touch due to work taking me away from Wicket development for a while, sorry about that.
But I really like this idea. For one, IModel is, in hindsight, clearly a thing that does *two* things. I could see it being changed to IReadableModel and IWriteableModel, with IModel simply extending from both (because the combination is still often useful). That might be useful even for distinguishing between input and output models. (this is probably just a restatement of the original proposal you mentioned, but it's been a while since I read it) And for another, since I like functional programming and don't like Java's boilerplate, I really like the idea of your examples here. So I'm +1 for this, as long as we aren't missing any major obstacles here. Carl-Eric On Tue, 28 Jan 2014 23:25:30 +0100 Martijn Dashorst <[email protected]> wrote: > Should we strive to ease the addition of lambda expressions to Wicket > by introducing single method interfaces in various places in Wicket 7? > > For a contrived example: > > AbstractLink#setBody(IModel<?> bodyModel) {} > > Could be: > > AbstractLink#setBody(IReadModel<?> bodyModel) {} > > So that you can do: > > link.setBody( () -> "Click me!" ); > > This would replace the old and tried: > > link.setBody( new AbstractReadOnlyModel<Object>() { > public Object getObject() { > return "Click me!"; > } > }); > > Of course this particular example is better done with Model.of("Click > me!"), but the lambda expression is what makes this more interesting. > > My proposal is to do what Michael Mosmann (iirc) has proposed > previously with splitting read and write of IModel, and use it to our > advantage in preparing for java 8 in various places. > > Components that are candidates for using Single Method Interface > models may include: > - Label > - AbstractLink#body > - Repeaters > - ... > > While I suppose it is early for us to consider full adoption of Java 8 > lambda's, I doubt it can really hurt us badly if we take this small > step. > > Martijn > > > > On Mon, Jan 27, 2014 at 2:36 PM, Martin Grigorov > <[email protected]>wrote: > > > Check > > https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+7.0 > > Also Jira filter > > https://issues.apache.org/jira/issues/?filter=12326080shows all > > tickets which are fixed only in 7.0.0. There are some new > > features which are not listed in the migration guide. > > There are no revolutionary changes. Only improvements which cannot > > be done in 6.x because of API breaks, behavior change or too risky > > for a minor version. > > > > Martin Grigorov > > Wicket Training and Consulting > > > > > > On Mon, Jan 27, 2014 at 2:30 PM, Nick Pratt <[email protected]> > > wrote: > > > > > So what's in 7.0 M1 apart from a few modules that are no longer > > > marked experimental? Is there anything significant in the core > > > Wicket lib? > > > > > > N > > > > > > > > > On Mon, Jan 27, 2014 at 6:41 AM, Martin Grigorov > > > <[email protected] > > > >wrote: > > > > > > > OK, bean-validation, cdi-1.1 and native-websocket modules have > > > > been > > made > > > > non-experimental. > > > > I think we can release 7.0.0.M1 (or whatever semver allows for > > milestone > > > > version). > > > > @Martijn: can you do the release ? > > > > > > > > Martin Grigorov > > > > Wicket Training and Consulting > > > > > > > > > > > > On Mon, Jan 20, 2014 at 1:23 PM, Martijn Dashorst < > > > > [email protected]> wrote: > > > > > > > > > On Mon, Jan 20, 2014 at 10:59 AM, Martin Grigorov < > > > [email protected]> > > > > > wrote: > > > > > > Yes, evaluating which experimental modules to become stable > > > > > > is an > > > entry > > > > > in > > > > > > the roadmap document but I intentionally left it out of this > > > discussion > > > > > > because I think it deserves more discussions. But since you > > > > > > started > > > ... > > > > > > > > > > > wicket-cdi-1.1 is very new. I guess no one uses it so far. > > > > > > Did Topicus migrated to 6.13 yet ? > > > > > > Igor did your product move to wicket-cdi-1.1 ? > > > > > > But since wicket-cdi-1.1 has evolved from wicket-cdi(-1.0) I > > believe > > > it > > > > > is > > > > > > mature enough to be part of the stable module in Wicket 7. > > > > > > > > > > We have CDI-1.1 in our current project. It has yet to reach > > > > > anything near a testing environment, but for development it > > > > > seems to work. > > > > > > > > > > > Wicket Bean Validation (JSR303) seems to be working fine. > > > > > > There > > were > > > > > just a > > > > > > few issues with it. I'm +1 to make it stable module. > > > > > > > > > > > > Wicket Native WebSockets: > > > > > > I personally like it and I'd like to make it even better > > > > > > based on > > > > users' > > > > > > feedback. > > > > > > We use it in an internal project. > > > > > > My only concern about making it stable is that it will be > > > > > > harder to > > > > make > > > > > > improvements(API breaks) when more people start to use it. > > > > > > I am +1 to make it stable. > > > > > > > > > > You can make it stable in 6.x, and break API until we release > > > > > 7.0 ;-) > > > > > > > > > > > Wicket-Bootstrap: I think this module should be removed. > > > > > > > > > > Yup. Though we should add a webjars resource reference into > > > > > wicket-extensions that enables easy inclusion of any webjar > > framework. > > > > > > > > > > > Wicket Examples NG can use Michael Haitz's > > > > > > Wicket-Bootstrap<https://github.com/l0rdn1kk0n/wicket-bootstrap> > > or > > > > > > move the code from the experimental Wicket-Bootstrap to its > > packages. > > > > > > > > > > I'd suggest remove Wicket Examples NG for now (move to a > > > > > branch or so). I can't see that any time is going into that > > > > > project for now, > > and > > > > > any time invested should rather go into the user guide and > > > > > fixing 7.0 issues. > > > > > > > > > > I'm not *that* heavily attached to these two projects. > > > > > > > > > > Martijn > > > > > > > > > > > > > > > > >
