Hi Sven
On Mon, Mar 14, 2016 at 1:23 PM, Sven Meier <[email protected]> wrote: > Hi Martin, > > speaking of someting to nuke - insteaf of: > > IModel<String> personNameModel = new > SupplierCachingModel<>(person::getName); > > Why not simply? > > IModel<String> personNameModel = > Model.loadableDetachable(person::getName); > > I didn't like the name "Supplier*Caching*Model" anyway. > It is there already https://github.com/apache/wicket/blob/static-factories-for-lambdas/wicket-core/src/main/java/org/apache/wicket/model/Model.java#L208 But I agree there is no need of SupplierCachingModel as a separate class. > > Regards > Sven > > > > > On 14.03.2016 12:36, Martin Grigorov wrote: > >> Yes! >> >> - IModel<String> personNameModel = new >> SupplierModel<>(person::getName); >> + IModel<String> personNameModel = person::getName; >> >> Definitely makes sense to make it shorter! >> >> I'll nuke it now! >> >> >> Martin Grigorov >> Wicket Training and Consulting >> https://twitter.com/mtgrigorov >> >> On Mon, Mar 14, 2016 at 10:55 AM, Sven Meier <[email protected]> wrote: >> >> Hi, >>> >>> IModel being a functional interface now, what's the use of SupplierModel >>> ? >>> IMHO we can get rid of it. >>> >>> Regards >>> Sven >>> >>> >>> >>> On 12.03.2016 23:39, Tobias Soloschenko wrote: >>> >>> Yep - I am very happy about it, too - cool features for wicket 8 :-) >>>> >>>> Great work all! >>>> >>>> kind regards >>>> >>>> Tobias >>>> >>>> Am 12.03.16 um 23:38 schrieb Sven Meier: >>>> >>>> As a bonus IModel is a @FunctionalInterface now and one can do things >>>>> >>>>>> like: >>>>>> >>>>>> new Link<String>("", () -> "abc") { >>>>>> @Override >>>>>> public void onClick() >>>>>> { >>>>>> // ... >>>>>> } >>>>>> }; >>>>>> >>>>>> Seems we're getting a grip on Wicket+lambdas finally :) >>>>> >>>>> Thanks >>>>> Sven >>>>> >>>>> >>>>> On 12.03.2016 23:13, Martin Grigorov wrote: >>>>> >>>>> On Sat, Mar 12, 2016 at 11:01 PM, Martin Grigorov < >>>>>> [email protected] >>>>>> wrote: >>>>>> >>>>>> On Sat, Mar 12, 2016 at 7:48 PM, Sven Meier <[email protected]> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>>> 1) >>>>>>>> we've been twiddling with read-only models for some time now, and >>>>>>>> IIRC it >>>>>>>> never quite worked out. >>>>>>>> I don't see much benefit in IReadOnlyModel as it is proposed now - >>>>>>>> perhaps I'm missing the point though. >>>>>>>> >>>>>>>> How about adding another default to IModel: >>>>>>>> >>>>>>>> default void setObject(final T object) { >>>>>>>> throw new UnsupportedOperationException(); >>>>>>>> } >>>>>>>> >>>>>>>> This way we can get rid of AbstractReadOnlyModel too :P >>>>>>>> >>>>>>>> A minor thing that bothers me here is that currently >>>>>>>> AROM#setObject() >>>>>>>> >>>>>>> is >>>>>>> final, so subclasses are effectively read only too. >>>>>>> By moving this method to IModel we cannot make any guarantees. >>>>>>> But I guess it will always be used as an anonymous inner class, as >>>>>>> AROM is >>>>>>> used now. If someone wants to have children then (s)he will have to >>>>>>> create >>>>>>> a custom class and there (s)he can make it 'final'. >>>>>>> Let's do it! >>>>>>> >>>>>>> As a bonus IModel is a @FunctionalInterface now and one can do things >>>>>>> >>>>>> like: >>>>>> >>>>>> new Link<String>("", () -> "abc") { >>>>>> @Override >>>>>> public void onClick() >>>>>> { >>>>>> // ... >>>>>> } >>>>>> }; >>>>>> >>>>>> >>>>>> >>>>>> 2) >>>>>>> >>>>>>>> I don't see a need for this. >>>>>>>> >>>>>>>> Have fun >>>>>>>> Sven >>>>>>>> >>>>>>>> >>>>>>>> how about adding a >>>>>>>> >>>>>>>> >>>>>>>> On 11.03.2016 22:54, Martin Grigorov wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>>> At "lambdas" [1] branch there are two more features: >>>>>>>>> >>>>>>>>> 1) IReadOnlyModel by Michael Mossman >>>>>>>>> >>>>>>>>> At the moment there are AbstractReadOnlyModel and SupplierModel >>>>>>>>> (extends >>>>>>>>> from AROM). >>>>>>>>> Initially while MM suggested IROM I thought it will be a parent >>>>>>>>> interface >>>>>>>>> of IModel but it is the opposite - IROM extends from IModel. >>>>>>>>> I don't see need of IROM. The classes look enough to me. >>>>>>>>> >>>>>>>>> 2) stream based iteration of container's children by Andrea Del >>>>>>>>> Bene >>>>>>>>> I have said my opinion before - the visitor approach is faster than >>>>>>>>> the >>>>>>>>> stream based one. >>>>>>>>> In addition we have to remove the deprecated >>>>>>>>> org.apache.wicket.util.iterator.AbstractHierarchyIterator and its >>>>>>>>> related >>>>>>>>> classes because it fails with StackoverflowError when used in a >>>>>>>>> page >>>>>>>>> with >>>>>>>>> bigger component tree. >>>>>>>>> So I don't see a reason for this feature. >>>>>>>>> >>>>>>>>> Your option on them ? >>>>>>>>> >>>>>>>>> 1. https://github.com/apache/wicket/compare/lambdas >>>>>>>>> >>>>>>>>> Martin Grigorov >>>>>>>>> Wicket Training and Consulting >>>>>>>>> https://twitter.com/mtgrigorov >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >
