[
https://issues.apache.org/jira/browse/WICKET-6569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Gerhards updated WICKET-6569:
-------------------------------------
Description:
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
was:
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.
> 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)
