Hi,
WDYT ? Do we need to implement #detach() in #map(), #filter(), etc ?
yes, I think this is a good idea: the returned model holds a reference
to the given model, so it should detach it.
Regards
Sven
On 24.05.2017 21:36, Martin Grigorov wrote:
On Tue, May 23, 2017 at 11:17 PM, Martin Grigorov <[email protected]>
wrote:
Hi,
On Tue, May 23, 2017 at 5:40 PM, Ihmehlmenn <[email protected]> wrote:
Hello everyone,
while trying out some of the very cool new features in Wicket 8,
specifically replacing PropertyModels with lambda expressions, I had a few
questions coming up. Most of them have been answered by the great guide
provided, but following things are still a bit unclear to me:
Thank you for testing the milestone release and for the feedback!
1) Read-Only Models
Let's say I want to replace the following PropertyModel for showing the
"name" property of a Person obejct in a Label
new PropertyModel<String>(personModel, "name");
with a lambda expression. Which of the following would be the best
approach
and why?
LambdaModel.of(personModel, Person::getName);
This way of using LambdaModel is indeed the same as the second way. The
advantage LambdaModel has is that you can also set a value when you use the
method with the Supplier.
personModel.map(Person::getName);
personModel.flatMap(...); // not quite sure yet when to use this one.
See
next question as well
The first two options seem to be identical at the first glance but I
noticed
that the LambdaModel does call detach() on the underlying base model (just
like the PropertyModel does), whereas the model created by the map()
method
doesn't seem to do that.
This is a good point!
I think it is a bug that should be fixed!
Actually here we use closure so adding #detach() is not possible unless the
body is rewritten to instantiate an IModel with #getObject() and #detach()
impls.
I am not sure it is worth it.
@Devs WDYT ? Do we need to implement #detach() in #map(), #filter(), etc ?
2) Readable/Writeable Models
The documentation has the following example for mapping a model to a
readable/writeable model of a property
IModel<String> personNameModel = personModel.flatMap(targetPerson ->
LambdaModel.of(
() -> targetPerson::getName, targetPerson::setName
));
Why is the call to flatMap() needed? Isn't just using the LambdaModel the
same but shorter?
IModel<String> personNameModel = LambdaModel.of(personModel,
Person::getName, Person::setName);
IModel#flatMap() is like java.util.Optional#flatMap().
It is useful when you already have another IModel impl that knows how to
set/get the name of a person.
LambdaModel#of(IModel<X>, SerializableFunction<X,R>,
SerializableBiConsumer<X,R>) is an easy way to create such IModel impl by
using Java 8 lambdas.
We should cross-reference them in the javadoc!
Another discussion on this topic: http://markmail.org/
message/m6l2w3ryqbdew2co
3) Constants in Models
In some cases I need to set a static constant value as read only model in
a
component. Up until now I simply used
Model.of(Constants.MY_STATIC_VALUE);
which probably results in the value being serialised into the session of
the
user.
The model and its content are serialized with the page.
The page is stored in the http session only after being rendered. Once you
move to another stateful page it is replaced by it and from there on it is
stored only on the disk.
Am I assuming correctly, that using following lambda expression as model
is
more "efficient", since the static constant isn't serialised anymore this
way?
() -> Constants.MY_STATIC_VALUE;
Correct!
The static constant won't be serialized but the closure will be.
So this version should be close memory-wise to using AbstractReadOnlyModel
for this use case but anonymous inner classes have a reference to the outer
instance and afaik lambdas don't have it.
Thanks to everybody pouring so much time into developing Wicket!
Daniel Radünz
--
View this message in context: http://apache-wicket.1842946.n
4.nabble.com/Questions-regarding-Wicket-8-and-lambda-express
ions-for-models-tp4677918.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
