Hi,
thanks for your comments!
>> whether those transformations should be done by a Model or
>> it would be better to be done by Functions and finally a Model
>> would consume the result
> my thoughts exactly: Chaining of functions is a broader topic. Note how
> ReadOnlyModel and LambdaColumn have identical #map() functions.
> Furthermore Java Function objects already support chaining with #andThen().
> The Java compiler just doesn't allow calling methods on a method reference:
> // doesn't work
> IModel<String> streetModel = LambdaModel.of(target,
> Person::getAdress.andThen(Address::getStreet));
I agree with both of you. The 'first' method is actually something Java 8 is
totally missing in my opinion, which is one reason for my ideas. The other one
being potential null values in the above, which we could rule out using
Optional:
LambdaModel.of(target, p ->
Optional.ofNullable(p).map(Person::getAddress).map(Address::getStreet).orElse("n/a"));
Maybe this is a better way to deal with this sort of chaining, because it's
actually the same approach for the 'LambdaColumn' and uses mechanisms, which
are more general. I think one could even make an argument to create a getter
for this case. The 'apply' could then be done in the following way:
LambdaModel.of(target, p -> Optional.ofNullable(p).
map(Person::getName).
map(name -> house.getObject().apply(name)).
orElse("n/a"));
> - if this functionality should be in a model then in which class?
> -- AbstractReadOnlyModel is deprecated. Maybe we should un-deprecate it ?!
> -- the name "ReadOnlyModel" doesn't tell me what nice functionality I
> could expect from it. But on the side all these methods should be provided
> only by a read-only model. Or not? I see they can easily be put in IModel
> class, but then the developer should be careful with the usage of
> #setObject()
Despite the above, I'll still answer this concern:
You are right. The naming is absolutely terrible and I have been struggling
with a good name not involving all the Haskell stuff I have been taking
inspiration from. At the moment I would tend to call it MappableModel<T>. In
light of the 8.x changes, I would let it implement IModel<T> - so no need for
un-deprecating AbstractReadOnlyModel<T>. This was just because I have been
playing around with 7.x. Yes, ReadOnlyModel and/or LoadableDetachableModel and
also maybe a MappableColumn. Basically everything which mostly reads.
I have been tinkering with a method '#toIModel(BiConsumer<T, U> setter)',
transforming the MappableModel to an IModel. That comes with some non-obvious
caveats however.
Have a nice rest of the day,
Matthias
----- Ursprüngliche Message -----
Von: Sven Meier <[email protected]>
An: [email protected]
Gesendet: 12:23 Sonntag, 24.April 2016
Betreff: Re: Further Lambda Model ideas
Hi,
> whether those transformations should be done by a Model or
> it would be better to be done by Functions and finally a Model
> would consume the result
my thoughts exactly: Chaining of functions is a broader topic. Note how
ReadOnlyModel and LambdaColumn have identical #map() functions.
Furthermore Java Function objects already support chaining with #andThen().
The Java compiler just doesn't allow calling methods on a method reference:
// doesn't work
IModel<String> streetModel = LambdaModel.of(target,
Person::getAdress.andThen(Address::getStreet));
You have to use a method call to get an actual function object first:
// this does work
IModel<String> streetModel = LambdaModel.of(target,
first(Person::getAdress).andThen(Address::getStreet));
private <T1, T2> WicketFunction<T1, T2> first(WicketFunction<T1,
T2> func) {
return func;
}
For this to work we have to add an additional method for serialization
into WicketFunction though:
// specialization of the super method for serializable functions
default <V> WicketFunction<T, V> andThen(WicketFunction<? super R,
? extends V> after)
{
Objects.requireNonNull(after);
return (T t) -> after.apply(apply(t));
}
Have fun
Sven
On 24.04.2016 11:34, Martin Grigorov wrote:
> On Sun, Apr 24, 2016 at 11:16 AM, Martin Grigorov <[email protected]>
> wrote:
>
>> Hi,
>>
>> I like the functionality provided by ReadOnlyModel!
>> I have two questions/doubts:
>> - whether those transformations should be done by a Model or it would be
>> better to be done by Functions and finally a Model would consume the result
>> - if this functionality should be in a model then in which class?
>> -- AbstractReadOnlyModel is deprecated. Maybe we should un-deprecate it ?!
>> -- the name "ReadOnlyModel" doesn't tell me what nice functionality I
>> could expect from it. But on the side all these methods should be provided
>> only by a read-only model. Or not? I see they can easily be put in IModel
>> class, but then the developer should be careful with the usage of
>> #setObject()
>>
>> I think a better solution would be a read-write Model that uses
>> composition of functions internally for all the transformations.
>> #setObject() will manipulate the model's object. #getObject() will apply
>> the model object to the composed function to get the final result.
>>
> This won't work. The mapping cannot be in the same IModel, a new IModel
> should be returned.
>
>
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Fri, Apr 22, 2016 at 10:52 PM, Matthias Metzger <
>> [email protected]> wrote:
>>
>>> Hi,
>>>
>>>
>>> thanks to all of you for the interest! I just added some examples to the
>>> README of my repository and implemented an alternative to/enhanced the
>>> LambdaColumn. Hope this makes your life a little easier. If there is
>>> anything else I can do for that matter, just hit me up.
>>>
>>>
>>> @Carl-Eric: I am very keen to see what you'll come up with. Mapping over
>>> everything with a <T> was the best I could think of, without resorting to
>>> reflection. :D
>>>
>>> Regards,
>>> Matthias
>>>
>>>
>>> ________________________________
>>> Von: Carl-Eric Menzel <[email protected]>
>>> An: [email protected]
>>> Gesendet: 10:10 Freitag, 22.April 2016
>>> Betreff: Re: Further Lambda Model ideas
>>>
>>>
>>> Hi Matthias,
>>>
>>> interesting ideas, thank you for sharing! I'm going to have a closer
>>> look either this weekend or next (a bit busy right now). Currently I'm
>>> working on some Java 8 helpers for Wicket 7, similar to the LambdaModel
>>> thing currently in WicketStuff. I'm doing that mostly to just play
>>> around with some ideas but also because I'm not entirely happy with the
>>> WicketStuff LambdaModel - basically I'm exploring to see whether I can
>>> come up with something I like better.
>>>
>>> Carl-Eric
>>>
>>>
>>> On Thu, 21 Apr 2016 20:19:52 +0000 (UTC)
>>> Matthias Metzger <[email protected]> wrote:
>>>
>>>> Hello everyone,
>>>> I just saw yesterday, that the IModel became/will become a
>>>> @FunctionalInterface in Wicket 8 and was very happy about it. I am
>>>> also very happy about the ongoing implementations and discussions
>>>> around lambda usage in Wicket, because it simplifies a lot of code.
>>>> Now, one thing I have been working on, is implementing some of the
>>>> now known methods of Stream<T> for a AbstractReadOnlyModel and also
>>>> for other things - like columns. I have not seen such discussions on
>>>> here, please forgive me if I missed that. If it has indeed not been
>>>> discussed and you find the idea useful, you can take a look at an
>>>> implementation in the following repository:
>>>>
>>> https://github.com/noobymatze/lambdawicket-model/blob/master/src/main/java/com/github/noobymatze/lambdawicket/model/ReadOnlyModel.java
>>>> What might we be able to do with that?
>>>> Consider a Person containing an Address, containing a Street with a
>>>> name. Now I want to display the name of the street. How would I go
>>>> about that?new Label("streetName", () ->
>>>> person.getAddress().getStreet().getName()); This is one approach, but
>>>> it completely ignores the possibility of null values and a default
>>>> value for such cases. I could wrap the above in an Optional or create
>>>> a method in the Person class like 'Optional<String> getStreetName()
>>>> {...}'.
>>>>
>>>> With the proposed ReadOnlyModel I could also do it in the following
>>>> way: new Label("streetName", ReadOnlyModel.of(person).
>>>> map(Person::getAddress). map(Address::getStreet).
>>>> map(Street::getName). orElse("n/a")); But that's not all. Imagine we
>>>> would need to dynamically truncate the streetName based on user
>>>> input: IModel<WicketFunction<String, String>> truncate = () -> str ->
>>>> str.length() > 10 ? str.substring(0, 10) + "..." : str;
>>>> IModel<String> truncatedStreetName = ReadOnlyModel.of(person).
>>>> map(Person::getAddress). map(Address::getStreet).
>>>> map(Street::getName). apply(truncate). orElse("n/a"); Now we
>>>> could switch the truncate Model using a
>>>> DropDownChoice<WicketFunction<String, String>> or by just setting the
>>>> contained function somewhere.truncate.setObject(str ->
>>>> str.substring(0, 20));
>>>>
>>>> The whole approach is - if I am not mistaken - heavier on memory,
>>>> because instead of one IModel<String> we now have 5 or 6 Models, that
>>>> cannot be garbage collected, because they are all needed to perform
>>>> the computation.
>>>>
>>>> This doesn't apply for mapping over an IColumn though, because it
>>>> doesn't need to rely on the laziness, like the ReadOnlyModel does
>>>> (otherwise a change in truncate wouldn't mean a change in the final
>>>> value), so:new LambdaColumn(of("Name"), Person::getAddress).
>>>> map(Address::getStreet). map(Street::getName). orElse("n/a"));
>>>> would create 4 new instances of the LambdaColumn, but 3 of them could
>>>> be gc'd more or less the second they were created - like I said, if I
>>>> am not mistaken. If this is at all an approach you think might be
>>>> useful, I would be happy to provide the implementation of the
>>>> LambdaColumn. Otherwise just ignore my message. :) Have a nice
>>>> day,Matthias
>>
