> I didn't want to put every idea directly in master.
Thanks to this procedure we've progressed a lot with lambdas :).
Thanks
Sven
On 14.03.2016 15:49, Martin Grigorov wrote:
I didn't want to put every idea directly in master.
First wanted to here opinions.
But I see how this makes it hard to follow.
I'll merge this branch to master and then we can just rework whatever we
find not optimal directly there.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Mar 14, 2016 at 3:16 PM, Sven Meier <[email protected]> wrote:
Hm, I starting to lose track of what is on which branch :/.
Sven
On 14.03.2016 14:09, Martin Grigorov wrote:
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
