[
https://issues.apache.org/jira/browse/WICKET-6569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16584256#comment-16584256
]
Sven Meier commented on WICKET-6569:
------------------------------------
Problem is the return of #setModelObject()
{code:java}
default C setModelObject(T object)
{
setDefaultModelObject(object);
return (C) this;
}{code}
This seems to confuse the compiler so it no longer chooses the right method
signature.
Why don't you pass the actual model to the child component?
> LambdaModel.of overload is ambiguous
> ------------------------------------
>
> Key: WICKET-6569
> URL: https://issues.apache.org/jira/browse/WICKET-6569
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 8.0.0
> Reporter: Michael Gerhards
> Priority: Minor
> Attachments: myproject.zip
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> a method call of
> LambdaModel.of(this::getModelObject, this::setModelObject)
> refers to
> public static <X, R> IModel<R> of(IModel<X> target, SerializableFunction<X,
> R> getter)
> but should be
> public static <R> IModel<R> of(SerializableSupplier<R> getter,
> SerializableConsumer<R> setter)
> The problem is that IModel and SerializableSupplier have functionally the
> same interface:
> T getObject(); vs. T get();
>
> Background:
> The child component should share its default model object with its parent
> component's default model object. So if setDefaultModelObject is called on
> the parent component than the child component should also refer to the new
> value (and with versa).
>
> Workaround:
> public Parent(String wicektId, IModel<Role> roleModel) {
> IModel<Role> childRoleModel = new IModel<Role>() {
> @Override
> public Role getObject()
> { return Parent.this.getModelObject(); }
> @Override
> public void setObject(Role object)
> { Parent.this.setModelObject(object); }
> };
> add(new Child("child", childRoleModel));
> }
>
> Solution:
> The problem only exists because .of Method is overloaded. If both methods
> would have different names (or be in different classes) than the compiler
> would be fine.
>
> Please see attached files
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
