[
https://issues.apache.org/jira/browse/WICKET-6569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16713051#comment-16713051
]
ASF subversion and git services commented on WICKET-6569:
---------------------------------------------------------
Commit 4f9b029fa32a9da0fa9aebc710443a202a435299 in wicket's branch
refs/heads/wicket-8.x from [~svenmeier]
[ https://git-wip-us.apache.org/repos/asf?p=wicket.git;h=4f9b029 ]
WICKET-6569 deprecated ambiguous method
> 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
> Fix For: 8.3.0, 9.0.0
>
> 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)
