Re: Does Wicket creates session (in work folder) when deployed on jboss?
Hi, See https://cwiki.apache.org/confluence/display/WICKET/Page+Storage Wicket serializes the used stateful pages in the disk for eventual later usage, for example your user clicks the browser back button. I'm not sure how this effects the performance though. The writing to the disk is done in a separate thread. You can disable it if you want by replacing one of IPageManager/IPageStore/IDataStore impls. On Thu, Sep 27, 2012 at 9:18 AM, shruts shruts.inn...@gmail.com wrote: My concern is .. I have developed an wicket application and running it on jboss. So Currently i'm able to see that when the jboss is started , the tmp and work folder are created parallelly to the server folder. And i could see that inside the work folder whatever my application is deployed ,with that name a folder is created and inside it there is something called as wicketfilter store where in i can see the session is created when i access my application. And this folder size is increasing on each request(for a particular user). So my question is related to these sessions creation. which means is this the default nature of the wicket to create sessions? Can we avoid creation of these sessions in jboss (Which is effecting my applications performance). If yes then how can we do so ? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Does-Wicket-creates-session-in-work-folder-when-deployed-on-jboss-tp4652363p4652395.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Component setDefaultModel
Hi, is there any usefull application of Component.setDefaultModel(...)? IMHO this Method is the cause for much trouble without any benefit. But maybe i did not understand when someone should replace a component model... thanks Michael
Re: Component setDefaultModel
Hi, Most of the time it is recommended to use a dynamic model, so there is no reason to replace the component's model. Component#setDefaultModel() gives you semi-dynamic nature - you can replace the model completely with a new one. Same with #setDefaultModelObject(). What is the problem you face with it ? On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann mich...@mosmann.de wrote: Hi, is there any usefull application of Component.setDefaultModel(...)? IMHO this Method is the cause for much trouble without any benefit. But maybe i did not understand when someone should replace a component model... thanks Michael -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Component setDefaultModel
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the
second only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected. If you call setDefaultModel you might think, that everything
is fine, but its not. A child component does not use
getParent().getDefaultModel() to get these changes. I saw a lot of code
like this, which leads to trouble, if you change the model and not the
value.
If there is no benefit in using setDefaultModel over
setDefaultModelObject i would like to remove this method. This could
prevent many you might not got the full picture how to use wicket the
right way errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so there is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann mich...@mosmann.de wrote:
Hi,
is there any usefull application of Component.setDefaultModel(...)? IMHO
this Method is the cause for much trouble without any benefit. But maybe i
did not understand when someone should replace a component model...
thanks
Michael
Re: Component setDefaultModel
Hi,
In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as expected.
If you call setDefaultModel you might think, that everything is fine, but
its not. A child component does not use getParent().getDefaultModel() to get
these changes. I saw a lot of code like this, which leads to trouble, if you
change the model and not the value.
If there is no benefit in using setDefaultModel over setDefaultModelObject i
would like to remove this method. This could prevent many you might not got
the full picture how to use wicket the right way errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so there is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann mich...@mosmann.de
wrote:
Hi,
is there any usefull application of Component.setDefaultModel(...)? IMHO
this Method is the cause for much trouble without any benefit. But maybe
i
did not understand when someone should replace a component model...
thanks
Michael
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Component setDefaultModel
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again in
an other way:
APanel uses model instance A and the label uses a property model
instance P which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance B,but
label uses model instance P which uses model instance A as before. So
the label does not see any changes, because no one tells the model
instance P, that it should use B instead of A. I think, there are rare
cases for such a usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as expected.
If you call setDefaultModel you might think, that everything is fine, but
its not. A child component does not use getParent().getDefaultModel() to get
these changes. I saw a lot of code like this, which leads to trouble, if you
change the model and not the value.
If there is no benefit in using setDefaultModel over setDefaultModelObject i
would like to remove this method. This could prevent many you might not got
the full picture how to use wicket the right way errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so there is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann mich...@mosmann.de
wrote:
Hi,
is there any usefull application of Component.setDefaultModel(...)? IMHO
this Method is the cause for much trouble without any benefit. But maybe
i
did not understand when someone should replace a component model...
thanks
Michael
Re: Component setDefaultModel
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann mich...@mosmann.de wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again in an
other way:
APanel uses model instance A and the label uses a property model instance P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance B,but
label uses model instance P which uses model instance A as before. So the
label does not see any changes, because no one tells the model instance P,
that it should use B instead of A. I think, there are rare cases for such a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is fine, but
its not. A child component does not use getParent().getDefaultModel() to
get
these changes. I saw a lot of code like this, which leads to trouble, if
you
change the model and not the value.
If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you might not
got
the full picture how to use wicket the right way errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so there is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann mich...@mosmann.de
wrote:
Hi,
is there any usefull application of Component.setDefaultModel(...)?
IMHO
this Method is the cause for much trouble without any benefit. But
maybe
i
did not understand when someone should replace a component model...
thanks
Michael
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: [vote] Release Apache Wicket 6.1.0
On 26.09.2012 15:26, Martijn Dashorst wrote: [X] No, don't release Apache Wicket 6.1.0, because ... the way URLs are encoded was changed (WICKET-4645) and now the first request (with ;jsessionid in path) generates invalid internal links: My page is mounted to /Home/ and I get redirected to /Home/;jsessionid=1234?0 (fine). There's a Link on the page and the generated URL for it is ../Home;jsessionid=1234?0-1.ILinkListener-link. Note the missing /. This results in a 404 and breaks basically all of my system tests. I can provide a quickstart if needed. Christoph
Re: Make attribute modifier a temporary behavior?
See
https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/master/library/src/main/java/de/agilecoders/wicket/markup/html/bootstrap/behavior
There are few CssClassName* classes which are a bit more sophisticated
than Wicket's AttributeModifier.
On Thu, Sep 27, 2012 at 12:28 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
I encounter the following code quite often in our company's codebase:
@Override
protected void onBeforeRender() {
add(AttributeModifier.replace(class, someCondition ? someValue
: someOtherValue));
}
This is of course a (often a minor) memory leak: each time the
component gets rendered, a new attribute modifier is added to the list
of behaviors, each overwriting the class attribute. The correct code
would of course be:
@Override
protected void onInitialize() {
add(AttributeModifier.replace(class, new
AbstractReadOnlyModelString() {
public String getObject() {
return someCondition ? someValue : someOtherValue;
}
}));
}
Another solution would be to make the attribute modifiers temporary.
Problem with that is silent failures of attributemodifiers added in
onInitialize and constructors or guarded by hasBeenRendered().
My main question is: do you encounter this kind of attribute
modification in your application code? Were you aware of this problem?
Martijn
PS. I guess it is time to write some blog articles about this...
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: [vote] Release Apache Wicket 6.1.0
Hi Christoph, Please create a new ticket with a quickstart. Thanks! On Thu, Sep 27, 2012 at 12:18 PM, Christoph Leiter m...@christophleiter.com wrote: On 26.09.2012 15:26, Martijn Dashorst wrote: [X] No, don't release Apache Wicket 6.1.0, because ... the way URLs are encoded was changed (WICKET-4645) and now the first request (with ;jsessionid in path) generates invalid internal links: My page is mounted to /Home/ and I get redirected to /Home/;jsessionid=1234?0 (fine). There's a Link on the page and the generated URL for it is ../Home;jsessionid=1234?0-1.ILinkListener-link. Note the missing /. This results in a 404 and breaks basically all of my system tests. I can provide a quickstart if needed. Christoph -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Make attribute modifier a temporary behavior?
On Thu, Sep 27, 2012 at 11:46 AM, Martin Grigorov mgrigo...@apache.org wrote: See https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/master/library/src/main/java/de/agilecoders/wicket/markup/html/bootstrap/behavior There are few CssClassName* classes which are a bit more sophisticated than Wicket's AttributeModifier. That is nice, but doesn't address the memory leak issue. Martijn
Re: Make attribute modifier a temporary behavior?
On Thu, Sep 27, 2012 at 1:00 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Thu, Sep 27, 2012 at 11:46 AM, Martin Grigorov mgrigo...@apache.org wrote: See https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/master/library/src/main/java/de/agilecoders/wicket/markup/html/bootstrap/behavior There are few CssClassName* classes which are a bit more sophisticated than Wicket's AttributeModifier. That is nice, but doesn't address the memory leak issue. By making the behavior temporary you will solve the memory issue but then the #onInitialize() use case will become broken. The attribute will be set only for the first render of the component. Any further re-renders will not have it. Martijn -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: [vote] Release Apache Wicket 6.1.0
Please create a new ticket with a quickstart. https://issues.apache.org/jira/browse/WICKET-4789
Re: [vote] Release Apache Wicket 6.1.0
+1 to release I've ran our selenium tests against 6.2.0-SNAPSHOT, which contains the same code as 6.1.0 and all tests pass. I've checked the release, and the files look ok and it builds fine. About WICKET-4789, it's a regression against 6.1.0, so I guess it should be fixed, but I see no reason to delay 6.1.0 for this issue as the usecase really is a cornercase. We can always do a 6.1.1 release next week with a fix for this issue, perhaps with one or two other issues that might surface. Best regards, Emond On Wednesday 26 September 2012 15:26:04 Martijn Dashorst wrote: All, It's been hard work, but I have managed to *finally* create a release candidate of Wicket 6.1.0. The release has been created by a script, but I doubt it is reusable by anyone not running the same configuration as myself (Mac OS X Mountain Lion, homebrew installations of gpg, gpg-agent, etc) Please download the source distributions found on my people.apache.org distribution area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.1.0 [ ] No, don't release Apache Wicket 6.1.0, because ... Distributions, changelog, keys and signatures can be found at: http://people.apache.org/~dashorst/wicket-6.1.0 Signature for apache-wicket-6.1.0.tar.gz: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iEYEABECAAYFAlBi+38ACgkQJBX8W/xy/UWrYwCdHWH/7QmqYQcqL1FdXS2E0BCR Ph8AoKKEJPUr8uhgnn86kl6I5NfURDZJ =SMVj -END PGP SIGNATURE- Signature for apache-wicket-6.1.0.zip: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iEYEABECAAYFAlBi+38ACgkQJBX8W/xy/UXpyACgivkLLUH3YFJXX5ol2NtLgL0h kPwAnRjsDq8EZvGmv8/VkDFAPf8yEui7 =jxFi -END PGP SIGNATURE- Martijn
Re: Component setDefaultModel
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel working on
the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model isn't changed
unattendedly.
IMHO changing a component's model isn't the wicket way so I'd suggest
changing the visibility of Component#setDefaultModel() to protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann mich...@mosmann.de wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again in an
other way:
APanel uses model instance A and the label uses a property model instance P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance B,but
label uses model instance P which uses model instance A as before. So the
label does not see any changes, because no one tells the model instance P,
that it should use B instead of A. I think, there are rare cases for such a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is fine, but
its not. A child component does not use getParent().getDefaultModel() to
get
these changes. I saw a lot of code like this, which leads to trouble, if
you
change the model and not the value.
If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you might not
got
the full picture how to use wicket the right way errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so there is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann mich...@mosmann.de
wrote:
Hi,
is there any usefull application of Component.setDefaultModel(...)?
IMHO
this Method is the cause for much trouble without any benefit. But
maybe
i
did not understand when someone should replace a component model...
thanks
Michael
Re: Component setDefaultModel
Am 27.09.2012 14:19, schrieb Sven Meier:
IMHO changing a component's model isn't the wicket way so I'd
suggest changing the visibility of Component#setDefaultModel() to
protected.
mark as deprecated and remove it later.. ?
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model
isn't changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd
suggest changing the visibility of Component#setDefaultModel() to
protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann
mich...@mosmann.de wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again
in an
other way:
APanel uses model instance A and the label uses a property model
instance P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as before.
So the
label does not see any changes, because no one tells the model
instance P,
that it should use B instead of A. I think, there are rare cases for
such a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is
fine, but
its not. A child component does not use
getParent().getDefaultModel() to
get
these changes. I saw a lot of code like this, which leads to
trouble, if
you
change the model and not the value.
If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you
might not
got
the full picture how to use wicket the right way errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so
there is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Hi,
is there any usefull application of Component.setDefaultModel(...)?
IMHO
this Method is the cause for much trouble without any benefit. But
maybe
i
did not understand when someone should replace a component model...
thanks
Michael
Re: Component setDefaultModel
There are calls to #setDefaultModel() from various places, e.g.
MarkupContainer and FormComponent.
I'm not sure we should disallow this usage completely (although it would
simplify MarkupContainer's handling of IComponentInheritedModel).
For me it would be enough to ease things for those who might not got
the whole picture, a *protected* would suffice for that.
Sven
On 09/27/2012 02:22 PM, Michael Mosmann wrote:
Am 27.09.2012 14:19, schrieb Sven Meier:
IMHO changing a component's model isn't the wicket way so I'd
suggest changing the visibility of Component#setDefaultModel() to
protected.
mark as deprecated and remove it later.. ?
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model
isn't changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd
suggest changing the visibility of Component#setDefaultModel() to
protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann
mich...@mosmann.de wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it
again in an
other way:
APanel uses model instance A and the label uses a property model
instance P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as before.
So the
label does not see any changes, because no one tells the model
instance P,
that it should use B instead of A. I think, there are rare cases
for such a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance,
the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is
fine, but
its not. A child component does not use
getParent().getDefaultModel() to
get
these changes. I saw a lot of code like this, which leads to
trouble, if
you
change the model and not the value.
If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you
might not
got
the full picture how to use wicket the right way errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so
there is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Hi,
is there any usefull application of
Component.setDefaultModel(...)?
IMHO
this Method is the cause for much trouble without any benefit. But
maybe
i
did not understand when someone should replace a component
model...
thanks
Michael
Re: Component setDefaultModel
changing a component's model isn't the wicket way so I'd suggest
changing the visibility of Component#setDefaultModel() to protected.
+1
IMHO, removing it not conceivable: imagine you want to set a model of a
Page, a LDM or CPM for instance, but you cannot supply it to the page's
super() (for any reason... you did not retrieved your pojo yet in case of a
CPM for instance). Then, have to call it explicitly later in the
constructor.
But I understand the issue, even that 's quite more a java concern than
something else as a model is designed to provide a wrapper arround an
object so the object can change, but the wrapper (model) reference have not
to... Anyway changing #setDefaultModel() to protected is a good option to
me and will prevent confusion.
Sebastien.
On Thu, Sep 27, 2012 at 2:22 PM, Michael Mosmann mich...@mosmann.de wrote:
Am 27.09.2012 14:19, schrieb Sven Meier:
IMHO changing a component's model isn't the wicket way so I'd suggest
changing the visibility of Component#setDefaultModel() to protected.
mark as deprecated and remove it later.. ?
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working on the old model:
aPanel.setDefaultModel(**otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model isn't
changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd suggest
changing the visibility of Component#setDefaultModel() to protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again in
an
other way:
APanel uses model instance A and the label uses a property model
instance P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance B,but
label uses model instance P which uses model instance A as before. So
the
label does not see any changes, because no one tells the model instance
P,
that it should use B instead of A. I think, there are rare cases for
such a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(**),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is fine,
but
its not. A child component does not use getParent().getDefaultModel()
to
get
these changes. I saw a lot of code like this, which leads to trouble,
if
you
change the model and not the value.
If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you might
not
got
the full picture how to use wicket the right way errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so there
is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann mich...@mosmann.de
wrote:
Hi,
is there any usefull application of Component.setDefaultModel(...)*
*?
IMHO
this Method is the cause for much trouble without any benefit. But
maybe
i
did not understand when someone should replace a component model...
thanks
Michael
Re: Make attribute modifier a temporary behavior?
On Thu, 27 Sep 2012 11:28:17 +0200
Martijn Dashorst martijn.dasho...@gmail.com wrote:
I encounter the following code quite often in our company's codebase:
@Override
protected void onBeforeRender() {
add(AttributeModifier.replace(class, someCondition ? someValue
: someOtherValue));
}
This is of course a (often a minor) memory leak: each time the
component gets rendered, a new attribute modifier is added to the list
of behaviors, each overwriting the class attribute. The correct code
would of course be:
This is simply a bug, in my opinion, and there's an easy fix that you
have already shown.
Changing AttributeModifier to become temporary would be a silent
behavior change that will very likely bite many more users than those
who have code with the shown bug. I haven't seen this in our codebase
at all, for example. But I'd certainly scratching my head if these
modifiers suddenly were to disappear after the first request.
So, my opinion is: -1. Better to improve documentation for this.
Carl-Eric
6.x config seems broken
Building Wicket 6 (master branch) mvn clean install -Pfast produces: [INFO] Building Wicket Examples 6.2.0-SNAPSHOT [INFO] Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-experimental/6.1-SNAPSHOT/maven-metadata.xml Downloaded: http://repository.apache.org/snapshots/org/apache/wicket/wicket-experimental/6.1-SNAPSHOT/maven-metadata.xml (609 B at 0.7 KB/sec) Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-parent/6.1-SNAPSHOT/maven-metadata.xml Downloaded: http://repository.apache.org/snapshots/org/apache/wicket/wicket-parent/6.1-SNAPSHOT/maven-metadata.xml (603 B at 1.3 KB/sec) [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ wicket-examples --- [INFO] Deleting /home/martin/git/apache/wicket/wicket-examples/target Wicket examples 6.2.0-SNAPSHOT needs *6.1-SNAPSHOT* -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: 6.x config seems broken
I have the latest code here. On Thu, Sep 27, 2012 at 5:33 PM, Andrea Del Bene an.delb...@gmail.com wrote: Martijn should have solved this problem with commit 4cf0aac Building Wicket 6 (master branch) mvn clean install -Pfast produces: [INFO] Building Wicket Examples 6.2.0-SNAPSHOT [INFO] Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-experimental/6.1-SNAPSHOT/maven-metadata.xml Downloaded: http://repository.apache.org/snapshots/org/apache/wicket/wicket-experimental/6.1-SNAPSHOT/maven-metadata.xml (609 B at 0.7 KB/sec) Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-parent/6.1-SNAPSHOT/maven-metadata.xml Downloaded: http://repository.apache.org/snapshots/org/apache/wicket/wicket-parent/6.1-SNAPSHOT/maven-metadata.xml (603 B at 1.3 KB/sec) [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ wicket-examples --- [INFO] Deleting /home/martin/git/apache/wicket/wicket-examples/target Wicket examples 6.2.0-SNAPSHOT needs *6.1-SNAPSHOT* -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Component setDefaultModel
Am 27.09.2012 17:32, schrieb Igor Vaynberg:
Hi,
.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().
Michael
-1 on changing setDefaultModel().
1) if B panel's model is truly dependent on A's then that dependency
should be expressed:
add(new BPanel(b, new PropertyModel(this, defaultModel));
or do not use the default model slot of B to store the model. that way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.
2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:
new DropDownChoice(foo).setModel(bar).setChoices(baz)...
this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.
-igor
On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel working
on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model isn't
changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd suggest
changing the visibility of Component#setDefaultModel() to protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again in
an
other way:
APanel uses model instance A and the label uses a property model instance
P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance B,but
label uses model instance P which uses model instance A as before. So the
label does not see any changes, because no one tells the model instance
P,
that it should use B instead of A. I think, there are rare cases for such
a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is fine,
but
its not. A child component does not use getParent().getDefaultModel()
to
get
these changes. I saw a lot of code like this, which leads to trouble,
if
you
change the model and not the value.
If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you might
not
got
the full picture how to use wicket the right way errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so there is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann mich...@mosmann.de
wrote:
Hi,
is there any usefull application of Component.setDefaultModel(...)?
IMHO
this Method is the cause for much trouble without any benefit. But
maybe
i
did not understand when someone should replace a component model...
thanks
Michael
Re: Component setDefaultModel
so what happens if panel A extends GenericPanel which has setModel?
you havent fixed anything.
-igor
On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de wrote:
Am 27.09.2012 17:32, schrieb Igor Vaynberg:
Hi,
.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().
Michael
-1 on changing setDefaultModel().
1) if B panel's model is truly dependent on A's then that dependency
should be expressed:
add(new BPanel(b, new PropertyModel(this, defaultModel));
or do not use the default model slot of B to store the model. that way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.
2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:
new DropDownChoice(foo).setModel(bar).setChoices(baz)...
this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.
-igor
On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working
on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model isn't
changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd suggest
changing the visibility of Component#setDefaultModel() to protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again in
an
other way:
APanel uses model instance A and the label uses a property model
instance
P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as before. So
the
label does not see any changes, because no one tells the model instance
P,
that it should use B instead of A. I think, there are rare cases for
such
a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is fine,
but
its not. A child component does not use getParent().getDefaultModel()
to
get
these changes. I saw a lot of code like this, which leads to trouble,
if
you
change the model and not the value.
If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you might
not
got
the full picture how to use wicket the right way errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so there
is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Hi,
is there any usefull application of Component.setDefaultModel(...)?
IMHO
this Method is the cause for
Re: Component setDefaultModel
Am 27.09.2012 17:51, schrieb Igor Vaynberg:
good point..
-1 from me.. thought it was a good idea, but wasn’t
Michael
so what happens if panel A extends GenericPanel which has setModel?
you havent fixed anything.
-igor
On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de wrote:
Am 27.09.2012 17:32, schrieb Igor Vaynberg:
Hi,
.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().
Michael
-1 on changing setDefaultModel().
1) if B panel's model is truly dependent on A's then that dependency
should be expressed:
add(new BPanel(b, new PropertyModel(this, defaultModel));
or do not use the default model slot of B to store the model. that way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.
2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:
new DropDownChoice(foo).setModel(bar).setChoices(baz)...
this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.
-igor
On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working
on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model isn't
changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd suggest
changing the visibility of Component#setDefaultModel() to protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again in
an
other way:
APanel uses model instance A and the label uses a property model
instance
P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as before. So
the
label does not see any changes, because no one tells the model instance
P,
that it should use B instead of A. I think, there are rare cases for
such
a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is fine,
but
its not. A child component does not use getParent().getDefaultModel()
to
get
these changes. I saw a lot of code like this, which leads to trouble,
if
you
change the model and not the value.
If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you might
not
got
the full picture how to use wicket the right way errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so there
is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Hi,
is there any usefull application of Component.setDefaultModel(...)?
IMHO
this Method is the
Re: Component setDefaultModel
If you extend GenericPanel you inherit setModel() and getModel(), that's
the whole purpose of this base class.
You want these two methods, otherwise you wouldn't extend it - there's
nothing to fix.
Component#setDefaultModel() is dangerous because it allows others to
tinker with your component innards.
I still think limiting access to #setDefaultModel() is a good idea, but
this is no crucial issue anyway.
Sven
On 09/27/2012 06:16 PM, Michael Mosmann wrote:
Am 27.09.2012 17:51, schrieb Igor Vaynberg:
good point..
-1 from me.. thought it was a good idea, but wasn’t
Michael
so what happens if panel A extends GenericPanel which has setModel?
you havent fixed anything.
-igor
On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 17:32, schrieb Igor Vaynberg:
Hi,
.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().
Michael
-1 on changing setDefaultModel().
1) if B panel's model is truly dependent on A's then that dependency
should be expressed:
add(new BPanel(b, new PropertyModel(this, defaultModel));
or do not use the default model slot of B to store the model. that way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.
2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:
new DropDownChoice(foo).setModel(bar).setChoices(baz)...
this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.
-igor
On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working
on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model
isn't
changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd
suggest
changing the visibility of Component#setDefaultModel() to protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it
again in
an
other way:
APanel uses model instance A and the label uses a property model
instance
P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as
before. So
the
label does not see any changes, because no one tells the model
instance
P,
that it should use B instead of A. I think, there are rare cases
for
such
a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel,
since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all
FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel
and
setDefaultModelObject .. the first one sets a new model
instance, the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and
works as
expected.
If you call setDefaultModel you might think, that everything
is fine,
but
its not. A child component does not use
getParent().getDefaultModel()
to
get
these changes. I saw a lot of code like this, which leads to
trouble,
if
you
change the model and not the value.
If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you
might
not
got
the full picture how to use wicket the right
Re: Component setDefaultModel
i thought the issue we were discussing here is the way the models are
linked...which is not solved by making setdefaultmodelobject
non-public.
-igor
On Thu, Sep 27, 2012 at 10:04 AM, Sven Meier s...@meiers.net wrote:
If you extend GenericPanel you inherit setModel() and getModel(), that's the
whole purpose of this base class.
You want these two methods, otherwise you wouldn't extend it - there's
nothing to fix.
Component#setDefaultModel() is dangerous because it allows others to tinker
with your component innards.
I still think limiting access to #setDefaultModel() is a good idea, but this
is no crucial issue anyway.
Sven
On 09/27/2012 06:16 PM, Michael Mosmann wrote:
Am 27.09.2012 17:51, schrieb Igor Vaynberg:
good point..
-1 from me.. thought it was a good idea, but wasn’t
Michael
so what happens if panel A extends GenericPanel which has setModel?
you havent fixed anything.
-igor
On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 17:32, schrieb Igor Vaynberg:
Hi,
.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().
Michael
-1 on changing setDefaultModel().
1) if B panel's model is truly dependent on A's then that dependency
should be expressed:
add(new BPanel(b, new PropertyModel(this, defaultModel));
or do not use the default model slot of B to store the model. that way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.
2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:
new DropDownChoice(foo).setModel(bar).setChoices(baz)...
this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.
-igor
On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working
on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model
isn't
changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd
suggest
changing the visibility of Component#setDefaultModel() to protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again
in
an
other way:
APanel uses model instance A and the label uses a property model
instance
P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as before.
So
the
label does not see any changes, because no one tells the model
instance
P,
that it should use B instead of A. I think, there are rare cases for
such
a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel,
since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all
FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance,
the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is
fine,
but
its not. A child component does not use
getParent().getDefaultModel()
to
get
these
Re: Component setDefaultModel
em. setdefaultmodel
-igor
On Thu, Sep 27, 2012 at 10:09 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
i thought the issue we were discussing here is the way the models are
linked...which is not solved by making setdefaultmodelobject
non-public.
-igor
On Thu, Sep 27, 2012 at 10:04 AM, Sven Meier s...@meiers.net wrote:
If you extend GenericPanel you inherit setModel() and getModel(), that's the
whole purpose of this base class.
You want these two methods, otherwise you wouldn't extend it - there's
nothing to fix.
Component#setDefaultModel() is dangerous because it allows others to tinker
with your component innards.
I still think limiting access to #setDefaultModel() is a good idea, but this
is no crucial issue anyway.
Sven
On 09/27/2012 06:16 PM, Michael Mosmann wrote:
Am 27.09.2012 17:51, schrieb Igor Vaynberg:
good point..
-1 from me.. thought it was a good idea, but wasn’t
Michael
so what happens if panel A extends GenericPanel which has setModel?
you havent fixed anything.
-igor
On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 17:32, schrieb Igor Vaynberg:
Hi,
.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().
Michael
-1 on changing setDefaultModel().
1) if B panel's model is truly dependent on A's then that dependency
should be expressed:
add(new BPanel(b, new PropertyModel(this, defaultModel));
or do not use the default model slot of B to store the model. that way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.
2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:
new DropDownChoice(foo).setModel(bar).setChoices(baz)...
this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.
-igor
On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working
on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model
isn't
changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd
suggest
changing the visibility of Component#setDefaultModel() to protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again
in
an
other way:
APanel uses model instance A and the label uses a property model
instance
P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as before.
So
the
label does not see any changes, because no one tells the model
instance
P,
that it should use B instead of A. I think, there are rare cases for
such
a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel,
since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all
FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance,
the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that
Re: Component setDefaultModel
We're discussing the case where a component distributes its model to its
children or behaviors.
For the component developer it's easier to assume that the model can't
be changed without its consensus (i.e. by offering a generic #setModel()).
Of course this can be handled perfectly by a coding guideline. I always
tell people to *never* change a component's model.
I cannot count times where I'm called to a developer's IDE with him
having absolutely no clue why something entered here doesn't display
over there: In many cases this is caused by setting models.
But a protected #setDefaultModelObject() would make this explicit in the
API.
Sven
On 09/27/2012 07:09 PM, Igor Vaynberg wrote:
i thought the issue we were discussing here is the way the models are
linked...which is not solved by making setdefaultmodelobject
non-public.
-igor
On Thu, Sep 27, 2012 at 10:04 AM, Sven Meier s...@meiers.net wrote:
If you extend GenericPanel you inherit setModel() and getModel(), that's the
whole purpose of this base class.
You want these two methods, otherwise you wouldn't extend it - there's
nothing to fix.
Component#setDefaultModel() is dangerous because it allows others to tinker
with your component innards.
I still think limiting access to #setDefaultModel() is a good idea, but this
is no crucial issue anyway.
Sven
On 09/27/2012 06:16 PM, Michael Mosmann wrote:
Am 27.09.2012 17:51, schrieb Igor Vaynberg:
good point..
-1 from me.. thought it was a good idea, but wasn’t
Michael
so what happens if panel A extends GenericPanel which has setModel?
you havent fixed anything.
-igor
On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 17:32, schrieb Igor Vaynberg:
Hi,
.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().
Michael
-1 on changing setDefaultModel().
1) if B panel's model is truly dependent on A's then that dependency
should be expressed:
add(new BPanel(b, new PropertyModel(this, defaultModel));
or do not use the default model slot of B to store the model. that way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.
2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:
new DropDownChoice(foo).setModel(bar).setChoices(baz)...
this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.
-igor
On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working
on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model
isn't
changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd
suggest
changing the visibility of Component#setDefaultModel() to protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again
in
an
other way:
APanel uses model instance A and the label uses a property model
instance
P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as before.
So
the
label does not see any changes, because no one tells the model
instance
P,
that it should use B instead of A. I think, there are rare cases for
such
a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel,
since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all
FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using
Re: [vote] Release Apache Wicket 6.1.0
[X] No, don't release Apache Wicket 6.1.0, because ... https://issues.apache.org/jira/browse/WICKET-4759 it's not a show-stopper but it's annoying if I have to subclass FilterForm to fix this issue. I've added a comment with a link to a Stackoverflow thread that discusses the issue of HTML forms without submit buttons. If there's a need to discuss this further I believe it can wait for a later wicket version and I vote yes, release Apache Wicket 6.1.0 now. -- Wolfgang Kritzinger
Re: Component setDefaultModel
On Thu, Sep 27, 2012 at 10:49 AM, Sven Meier s...@meiers.net wrote:
We're discussing the case where a component distributes its model to its
children or behaviors.
For the component developer it's easier to assume that the model can't be
changed without its consensus (i.e. by offering a generic #setModel()).
Of course this can be handled perfectly by a coding guideline. I always tell
people to *never* change a component's model.
I cannot count times where I'm called to a developer's IDE with him having
absolutely no clue why something entered here doesn't display over there: In
many cases this is caused by setting models.
But a protected #setDefaultModelObject() would make this explicit in the
API.
ok. lets start with a bit of history to have more context.
setDefaultModel() only exists because of type-erasure. before wicket
supported generics all components had a public setModel() method. so,
one might say that having a public setModel() is the wicket way
because it was there since 1.0. just to establish the baseline.
lets take a concrete example of FormComponent. right now it has a
public setModel() method, but by your thinking we would have to make
both setDefaultModel and setModel methods protected, because we do not
know that all FormComponents support changing the model. after all, a
common subclass of FormComponent is FormComponentPanel which pretty
much always distributes its model. so, we leave it to subclasses of
FormComponent and FormComponentPanel to decide whether or not to
override setModel() to make it public.
a TextField would make its setModel() public - because it properly
handles the usecase, correct? so it is still possible for your
developers to call setModel() on a textfield and rewire it so it no
longer links with a model of another component correctly.
so we are now back to square one with the addition that a lot of
components have to override setModel() just to change its visibility
from protected to public - introducing a lot of noise.
im all for making the code better, but i do not think that this change
does. in the end, the developer has to know what the method does if
they chose to call it.
-igor
Sven
On 09/27/2012 07:09 PM, Igor Vaynberg wrote:
i thought the issue we were discussing here is the way the models are
linked...which is not solved by making setdefaultmodelobject
non-public.
-igor
On Thu, Sep 27, 2012 at 10:04 AM, Sven Meier s...@meiers.net wrote:
If you extend GenericPanel you inherit setModel() and getModel(), that's
the
whole purpose of this base class.
You want these two methods, otherwise you wouldn't extend it - there's
nothing to fix.
Component#setDefaultModel() is dangerous because it allows others to
tinker
with your component innards.
I still think limiting access to #setDefaultModel() is a good idea, but
this
is no crucial issue anyway.
Sven
On 09/27/2012 06:16 PM, Michael Mosmann wrote:
Am 27.09.2012 17:51, schrieb Igor Vaynberg:
good point..
-1 from me.. thought it was a good idea, but wasn’t
Michael
so what happens if panel A extends GenericPanel which has setModel?
you havent fixed anything.
-igor
On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 17:32, schrieb Igor Vaynberg:
Hi,
.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().
Michael
-1 on changing setDefaultModel().
1) if B panel's model is truly dependent on A's then that dependency
should be expressed:
add(new BPanel(b, new PropertyModel(this, defaultModel));
or do not use the default model slot of B to store the model. that
way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.
2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through
the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:
new DropDownChoice(foo).setModel(bar).setChoices(baz)...
this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.
-igor
On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working
on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this,
defaultModel)));
But it would be much easier if APanel could assume that its model
isn't
changed unattendedly.
IMHO changing a component's model
Re: Component setDefaultModel
lets take a concrete example of FormComponent ... your thinking we would have to make both setDefaultModel and setModel methods protected Nope, I just ruminated about making setDefaultModel protected. a common subclass of FormComponent is FormComponentPanel which pretty much always distributes its model. In my experience FormComponentPanels are often highly specialized components developed by senior developers. Perhaps there are a handful of these in a project, most other cases are just nested panels. in the end, the developer has to know what the method does if they chose to call it. Agreed. Just one little nitpick: In my scenario it's two developers, one who has to safeguard against another developer calling a method he isn't suppose to call. Sven On 09/27/2012 08:59 PM, Igor Vaynberg wrote: On Thu, Sep 27, 2012 at 10:49 AM, Sven Meier s...@meiers.net wrote: We're discussing the case where a component distributes its model to its children or behaviors. For the component developer it's easier to assume that the model can't be changed without its consensus (i.e. by offering a generic #setModel()). Of course this can be handled perfectly by a coding guideline. I always tell people to *never* change a component's model. I cannot count times where I'm called to a developer's IDE with him having absolutely no clue why something entered here doesn't display over there: In many cases this is caused by setting models. But a protected #setDefaultModelObject() would make this explicit in the API. ok. lets start with a bit of history to have more context. setDefaultModel() only exists because of type-erasure. before wicket supported generics all components had a public setModel() method. so, one might say that having a public setModel() is the wicket way because it was there since 1.0. just to establish the baseline. lets take a concrete example of FormComponent. right now it has a public setModel() method, but by your thinking we would have to make both setDefaultModel and setModel methods protected, because we do not know that all FormComponents support changing the model. after all, a common subclass of FormComponent is FormComponentPanel which pretty much always distributes its model. so, we leave it to subclasses of FormComponent and FormComponentPanel to decide whether or not to override setModel() to make it public. a TextField would make its setModel() public - because it properly handles the usecase, correct? so it is still possible for your developers to call setModel() on a textfield and rewire it so it no longer links with a model of another component correctly. so we are now back to square one with the addition that a lot of components have to override setModel() just to change its visibility from protected to public - introducing a lot of noise. im all for making the code better, but i do not think that this change does. in the end, the developer has to know what the method does if they chose to call it. -igor Sven On 09/27/2012 07:09 PM, Igor Vaynberg wrote: i thought the issue we were discussing here is the way the models are linked...which is not solved by making setdefaultmodelobject non-public. -igor On Thu, Sep 27, 2012 at 10:04 AM, Sven Meier s...@meiers.net wrote: If you extend GenericPanel you inherit setModel() and getModel(), that's the whole purpose of this base class. You want these two methods, otherwise you wouldn't extend it - there's nothing to fix. Component#setDefaultModel() is dangerous because it allows others to tinker with your component innards. I still think limiting access to #setDefaultModel() is a good idea, but this is no crucial issue anyway. Sven On 09/27/2012 06:16 PM, Michael Mosmann wrote: Am 27.09.2012 17:51, schrieb Igor Vaynberg: good point.. -1 from me.. thought it was a good idea, but wasn’t Michael so what happens if panel A extends GenericPanel which has setModel? you havent fixed anything. -igor On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de wrote: Am 27.09.2012 17:32, schrieb Igor Vaynberg: Hi, .. i would leave setModel as it is, only make this change for Component.setDefaultModel(). Michael -1 on changing setDefaultModel(). 1) if B panel's model is truly dependent on A's then that dependency should be expressed: add(new BPanel(b, new PropertyModel(this, defaultModel)); or do not use the default model slot of B to store the model. that way setDefaultModel() calls on B will be a noop and you can choose not to provide a setter. 2) you are only solving this for a subset of usecases where the container (A) is not generic. are we also going to make setModel(T) protected? that would require the model assignment be done through the constructor only and would eliminate any possibility of writing builder-style code. consider a simple example: new DropDownChoice(foo).setModel(bar).setChoices(baz)... this kind of code should be possible whether written directly by the developer in the
Re: Component setDefaultModel
On Thu, Sep 27, 2012 at 1:59 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: ok. lets start with a bit of history to have more context. setDefaultModel() only exists because of type-erasure. before wicket supported generics all components had a public setModel() method. so, one might say that having a public setModel() is the wicket way because it was there since 1.0. just to establish the baseline. lets take a concrete example of FormComponent. right now it has a public setModel() method, but by your thinking we would have to make both setDefaultModel and setModel methods protected, because we do not know that all FormComponents support changing the model. after all, a common subclass of FormComponent is FormComponentPanel which pretty much always distributes its model. so, we leave it to subclasses of FormComponent and FormComponentPanel to decide whether or not to override setModel() to make it public. a TextField would make its setModel() public - because it properly handles the usecase, correct? so it is still possible for your developers to call setModel() on a textfield and rewire it so it no longer links with a model of another component correctly. so we are now back to square one with the addition that a lot of components have to override setModel() just to change its visibility from protected to public - introducing a lot of noise. im all for making the code better, but i do not think that this change does. in the end, the developer has to know what the method does if they chose to call it. -igor +100 ... there are valid usecases for calling setModel and setDefaultModel. Very valid usecases. If you, in your programming model, don't want your developers to call setModel/setDefaultModel ... tell them not to. If you have developers that don't understand / listen to / follow your direction, it's not a Wicket problem. For that, set up some kind of code-check that looks for that and other conventions that you follow. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Component setDefaultModel
On Thu, Sep 27, 2012 at 10:29 PM, Sven Meier s...@meiers.net wrote: lets take a concrete example of FormComponent ... your thinking we would have to make both setDefaultModel and setModel methods protected Nope, I just ruminated about making setDefaultModel protected. a common subclass of FormComponent is FormComponentPanel which pretty much always distributes its model. In my experience FormComponentPanels are often highly specialized components developed by senior developers. Perhaps there are a handful of these in a project, most other cases are just nested panels. in the end, the developer has to know what the method does if they chose to call it. Agreed. Just one little nitpick: In my scenario it's two developers, one who has to safeguard against another developer calling a method he isn't suppose to call. I think Michael Mossman is in the same situation. And I understand what you see as an improvement that will protect the average developer. But I don't like that: - this change will lead to an inconsistent API - setDefaultModel() and seModel() are basically the same method. Just #setModel() has some help from the compiler - this will make more advanced developer more unconfortable - he has to extend the component just to make the method public to be able to use it for his needs. And sooner or later every average developer becomes advanced... Sven On 09/27/2012 08:59 PM, Igor Vaynberg wrote: On Thu, Sep 27, 2012 at 10:49 AM, Sven Meier s...@meiers.net wrote: We're discussing the case where a component distributes its model to its children or behaviors. For the component developer it's easier to assume that the model can't be changed without its consensus (i.e. by offering a generic #setModel()). Of course this can be handled perfectly by a coding guideline. I always tell people to *never* change a component's model. I cannot count times where I'm called to a developer's IDE with him having absolutely no clue why something entered here doesn't display over there: In many cases this is caused by setting models. But a protected #setDefaultModelObject() would make this explicit in the API. ok. lets start with a bit of history to have more context. setDefaultModel() only exists because of type-erasure. before wicket supported generics all components had a public setModel() method. so, one might say that having a public setModel() is the wicket way because it was there since 1.0. just to establish the baseline. lets take a concrete example of FormComponent. right now it has a public setModel() method, but by your thinking we would have to make both setDefaultModel and setModel methods protected, because we do not know that all FormComponents support changing the model. after all, a common subclass of FormComponent is FormComponentPanel which pretty much always distributes its model. so, we leave it to subclasses of FormComponent and FormComponentPanel to decide whether or not to override setModel() to make it public. a TextField would make its setModel() public - because it properly handles the usecase, correct? so it is still possible for your developers to call setModel() on a textfield and rewire it so it no longer links with a model of another component correctly. so we are now back to square one with the addition that a lot of components have to override setModel() just to change its visibility from protected to public - introducing a lot of noise. im all for making the code better, but i do not think that this change does. in the end, the developer has to know what the method does if they chose to call it. -igor Sven On 09/27/2012 07:09 PM, Igor Vaynberg wrote: i thought the issue we were discussing here is the way the models are linked...which is not solved by making setdefaultmodelobject non-public. -igor On Thu, Sep 27, 2012 at 10:04 AM, Sven Meier s...@meiers.net wrote: If you extend GenericPanel you inherit setModel() and getModel(), that's the whole purpose of this base class. You want these two methods, otherwise you wouldn't extend it - there's nothing to fix. Component#setDefaultModel() is dangerous because it allows others to tinker with your component innards. I still think limiting access to #setDefaultModel() is a good idea, but this is no crucial issue anyway. Sven On 09/27/2012 06:16 PM, Michael Mosmann wrote: Am 27.09.2012 17:51, schrieb Igor Vaynberg: good point.. -1 from me.. thought it was a good idea, but wasn’t Michael so what happens if panel A extends GenericPanel which has setModel? you havent fixed anything. -igor On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de wrote: Am 27.09.2012 17:32, schrieb Igor Vaynberg: Hi, .. i would leave setModel as it is, only make this change for Component.setDefaultModel(). Michael -1 on changing setDefaultModel(). 1) if B panel's model is truly dependent on A's then that
Re: Component setDefaultModel
this will make more advanced developer more unconfortable I hear that ;). Jeremy gave a good suggestion: set up some kind of code-check Sven On 09/27/2012 09:38 PM, Martin Grigorov wrote: On Thu, Sep 27, 2012 at 10:29 PM, Sven Meier s...@meiers.net wrote: lets take a concrete example of FormComponent ... your thinking we would have to make both setDefaultModel and setModel methods protected Nope, I just ruminated about making setDefaultModel protected. a common subclass of FormComponent is FormComponentPanel which pretty much always distributes its model. In my experience FormComponentPanels are often highly specialized components developed by senior developers. Perhaps there are a handful of these in a project, most other cases are just nested panels. in the end, the developer has to know what the method does if they chose to call it. Agreed. Just one little nitpick: In my scenario it's two developers, one who has to safeguard against another developer calling a method he isn't suppose to call. I think Michael Mossman is in the same situation. And I understand what you see as an improvement that will protect the average developer. But I don't like that: - this change will lead to an inconsistent API - setDefaultModel() and seModel() are basically the same method. Just #setModel() has some help from the compiler - this will make more advanced developer more unconfortable - he has to extend the component just to make the method public to be able to use it for his needs. And sooner or later every average developer becomes advanced... Sven On 09/27/2012 08:59 PM, Igor Vaynberg wrote: On Thu, Sep 27, 2012 at 10:49 AM, Sven Meier s...@meiers.net wrote: We're discussing the case where a component distributes its model to its children or behaviors. For the component developer it's easier to assume that the model can't be changed without its consensus (i.e. by offering a generic #setModel()). Of course this can be handled perfectly by a coding guideline. I always tell people to *never* change a component's model. I cannot count times where I'm called to a developer's IDE with him having absolutely no clue why something entered here doesn't display over there: In many cases this is caused by setting models. But a protected #setDefaultModelObject() would make this explicit in the API. ok. lets start with a bit of history to have more context. setDefaultModel() only exists because of type-erasure. before wicket supported generics all components had a public setModel() method. so, one might say that having a public setModel() is the wicket way because it was there since 1.0. just to establish the baseline. lets take a concrete example of FormComponent. right now it has a public setModel() method, but by your thinking we would have to make both setDefaultModel and setModel methods protected, because we do not know that all FormComponents support changing the model. after all, a common subclass of FormComponent is FormComponentPanel which pretty much always distributes its model. so, we leave it to subclasses of FormComponent and FormComponentPanel to decide whether or not to override setModel() to make it public. a TextField would make its setModel() public - because it properly handles the usecase, correct? so it is still possible for your developers to call setModel() on a textfield and rewire it so it no longer links with a model of another component correctly. so we are now back to square one with the addition that a lot of components have to override setModel() just to change its visibility from protected to public - introducing a lot of noise. im all for making the code better, but i do not think that this change does. in the end, the developer has to know what the method does if they chose to call it. -igor Sven On 09/27/2012 07:09 PM, Igor Vaynberg wrote: i thought the issue we were discussing here is the way the models are linked...which is not solved by making setdefaultmodelobject non-public. -igor On Thu, Sep 27, 2012 at 10:04 AM, Sven Meier s...@meiers.net wrote: If you extend GenericPanel you inherit setModel() and getModel(), that's the whole purpose of this base class. You want these two methods, otherwise you wouldn't extend it - there's nothing to fix. Component#setDefaultModel() is dangerous because it allows others to tinker with your component innards. I still think limiting access to #setDefaultModel() is a good idea, but this is no crucial issue anyway. Sven On 09/27/2012 06:16 PM, Michael Mosmann wrote: Am 27.09.2012 17:51, schrieb Igor Vaynberg: good point.. -1 from me.. thought it was a good idea, but wasn’t Michael so what happens if panel A extends GenericPanel which has setModel? you havent fixed anything. -igor On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de wrote: Am 27.09.2012 17:32, schrieb Igor Vaynberg: Hi, .. i would leave setModel as it is, only make this change for Component.setDefaultModel().
Re: Component setDefaultModel
On Thu, Sep 27, 2012 at 10:45 PM, Sven Meier s...@meiers.net wrote:
this will make more advanced developer more unconfortable
I hear that ;).
Jeremy gave a good suggestion: set up some kind of code-check
Well this is an option but again it makes more advanced developers not
feeling comfortable.
For example: recently I had to suppress such CheckStyle check for the
usage of PageParameters#add() in our app because a colleague of mine
earlier had a bug with getPageParameters().add() and use this
parameters for the generation of a new Url. The side effect was that
after that call the current page instance had few more parameters and
this leaded to the bug.
In my case I really wanted to use #add() because I wanted to add
several values. A perfectly valid case.
So now we have: https://issues.apache.org/jira/browse/WICKET-4774
Here is another suggestion for the archives :-)
trait Advanced { self: Component =
def setDefaultModel(model: IModel) { ... }
}
val myComponent = new Label(id, text) with Advanced
myComponent.setDefaultModel(Model.of(advancedText))
without with Advanced you wont be able to see #setDefaultModel
(assuming that it is removed from Component API)
Sven
On 09/27/2012 09:38 PM, Martin Grigorov wrote:
On Thu, Sep 27, 2012 at 10:29 PM, Sven Meier s...@meiers.net wrote:
lets take a concrete example of FormComponent ... your thinking we would
have to make
both setDefaultModel and setModel methods protected
Nope, I just ruminated about making setDefaultModel protected.
a common subclass of FormComponent is FormComponentPanel which pretty
much always distributes its model.
In my experience FormComponentPanels are often highly specialized
components
developed by senior developers. Perhaps there are a handful of these in a
project, most other cases are just nested panels.
in the end, the developer has to know what the method
does if they chose to call it.
Agreed.
Just one little nitpick: In my scenario it's two developers, one who has
to
safeguard against another developer calling a method he isn't suppose to
call.
I think Michael Mossman is in the same situation.
And I understand what you see as an improvement that will protect the
average developer.
But I don't like that:
- this change will lead to an inconsistent API - setDefaultModel() and
seModel() are basically the same method. Just #setModel() has some
help from the compiler
- this will make more advanced developer more unconfortable - he has
to extend the component just to make the method public to be able to
use it for his needs. And sooner or later every average developer
becomes advanced...
Sven
On 09/27/2012 08:59 PM, Igor Vaynberg wrote:
On Thu, Sep 27, 2012 at 10:49 AM, Sven Meier s...@meiers.net wrote:
We're discussing the case where a component distributes its model to
its
children or behaviors.
For the component developer it's easier to assume that the model can't
be
changed without its consensus (i.e. by offering a generic #setModel()).
Of course this can be handled perfectly by a coding guideline. I always
tell
people to *never* change a component's model.
I cannot count times where I'm called to a developer's IDE with him
having
absolutely no clue why something entered here doesn't display over
there:
In
many cases this is caused by setting models.
But a protected #setDefaultModelObject() would make this explicit in
the
API.
ok. lets start with a bit of history to have more context.
setDefaultModel() only exists because of type-erasure. before wicket
supported generics all components had a public setModel() method. so,
one might say that having a public setModel() is the wicket way
because it was there since 1.0. just to establish the baseline.
lets take a concrete example of FormComponent. right now it has a
public setModel() method, but by your thinking we would have to make
both setDefaultModel and setModel methods protected, because we do not
know that all FormComponents support changing the model. after all, a
common subclass of FormComponent is FormComponentPanel which pretty
much always distributes its model. so, we leave it to subclasses of
FormComponent and FormComponentPanel to decide whether or not to
override setModel() to make it public.
a TextField would make its setModel() public - because it properly
handles the usecase, correct? so it is still possible for your
developers to call setModel() on a textfield and rewire it so it no
longer links with a model of another component correctly.
so we are now back to square one with the addition that a lot of
components have to override setModel() just to change its visibility
from protected to public - introducing a lot of noise.
im all for making the code better, but i do not think that this change
does. in the end, the developer has to know what the method does if
they chose to call it.
-igor
Sven
On 09/27/2012 07:09 PM, Igor Vaynberg
Re: 6.x config seems broken
I am unable to find a dependency on 6.1-SNAPSHOT in my local workspace and I don't have any commits that need to be pushed... Martijn On Thu, Sep 27, 2012 at 4:48 PM, Martin Grigorov mgrigo...@apache.org wrote: I have the latest code here. On Thu, Sep 27, 2012 at 5:33 PM, Andrea Del Bene an.delb...@gmail.com wrote: Martijn should have solved this problem with commit 4cf0aac Building Wicket 6 (master branch) mvn clean install -Pfast produces: [INFO] Building Wicket Examples 6.2.0-SNAPSHOT [INFO] Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-experimental/6.1-SNAPSHOT/maven-metadata.xml Downloaded: http://repository.apache.org/snapshots/org/apache/wicket/wicket-experimental/6.1-SNAPSHOT/maven-metadata.xml (609 B at 0.7 KB/sec) Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-parent/6.1-SNAPSHOT/maven-metadata.xml Downloaded: http://repository.apache.org/snapshots/org/apache/wicket/wicket-parent/6.1-SNAPSHOT/maven-metadata.xml (603 B at 1.3 KB/sec) [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ wicket-examples --- [INFO] Deleting /home/martin/git/apache/wicket/wicket-examples/target Wicket examples 6.2.0-SNAPSHOT needs *6.1-SNAPSHOT* -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Component setDefaultModel
On Thu, Sep 27, 2012 at 3:33 PM, tetsuo ronald.tet...@gmail.com wrote: What about calling APanel.setDefaultModelObject(B.getObject()) instead of APanel.setDefaultModel(B)? That's to replace an object inside a model. There are very valid usecases for actually replacing a model. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Component setDefaultModel
Couldn't it be solved with a delegate model? It wouldn't be 100% transparent, because the one who changes the underlying model would need to know that the container's model is a delegating model, but works perfectly. Well, but if you guys are so eager to break things... what about this: make getDefaultModel() never return the assigned model directly, but a wrapper, that delegates to the real one (assigned by setDefaultModel()). That way, any component that calls getParent().getDefaultModel() will automatically get the new model. All code out there that relies on 'if (getDefaultModel() instanceof XXX)' will break (since it will return the wrapper), but this edge case will work. On Thu, Sep 27, 2012 at 7:18 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Thu, Sep 27, 2012 at 3:33 PM, tetsuo ronald.tet...@gmail.com wrote: What about calling APanel.setDefaultModelObject(B.getObject()) instead of APanel.setDefaultModel(B)? That's to replace an object inside a model. There are very valid usecases for actually replacing a model. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
RE: 6.x config seems broken
This may be a stupid question but have you tried simply running a mvn clean before running your build command? Tom Burton -Original Message- From: Martijn Dashorst [mailto:martijn.dasho...@gmail.com] Sent: Thursday, September 27, 2012 12:14 PM To: dev@wicket.apache.org Subject: Re: 6.x config seems broken I am unable to find a dependency on 6.1-SNAPSHOT in my local workspace and I don't have any commits that need to be pushed... Martijn On Thu, Sep 27, 2012 at 4:48 PM, Martin Grigorov mgrigo...@apache.org wrote: I have the latest code here. On Thu, Sep 27, 2012 at 5:33 PM, Andrea Del Bene an.delb...@gmail.com wrote: Martijn should have solved this problem with commit 4cf0aac Building Wicket 6 (master branch) mvn clean install -Pfast produces: [INFO] Building Wicket Examples 6.2.0-SNAPSHOT [INFO] Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-expe rimental/6.1-SNAPSHOT/maven-metadata.xml Downloaded: http://repository.apache.org/snapshots/org/apache/wicket/wicket-expe rimental/6.1-SNAPSHOT/maven-metadata.xml (609 B at 0.7 KB/sec) Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-pare nt/6.1-SNAPSHOT/maven-metadata.xml Downloaded: http://repository.apache.org/snapshots/org/apache/wicket/wicket-pare nt/6.1-SNAPSHOT/maven-metadata.xml (603 B at 1.3 KB/sec) [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ wicket-examples --- [INFO] Deleting /home/martin/git/apache/wicket/wicket-examples/target Wicket examples 6.2.0-SNAPSHOT needs *6.1-SNAPSHOT* -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Become a Wicket expert, learn from the best: http://wicketinaction.com
