Hi,

I found a nice additional usage for LambdaModel. With static factory methods you can use it in two ways now:

IModel<String> personNameModel = LambdaModel.of(person::getName, person::setName);

... or if you have a model ...

IModel<String> personNameModel = LambdaModel.of(personModel, Person::getName, Person::setName);

Let me know if you'd rather have a separate class for this.

Have fun
Sven


On 14.03.2016 22:53, Martin Grigorov wrote:
I've checked all other IModel implementations but I didn't see more
candidates for lambd-ification.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, Mar 14, 2016 at 4:15 PM, Martin Grigorov <[email protected]>
wrote:

I've merged that branch.
Now the Lambdas class with the factory methods for components and
behaviors is also in master.
Any ideas for improvements are welcome!

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, Mar 14, 2016 at 4:01 PM, Sven Meier <[email protected]> wrote:

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







Reply via email to