Moving to the list as suggested by Gwyn.
From Jira issue:
https://issues.apache.org/jira/browse/WICKET-1108
Maybe I wasn't clear on what my problem with it was.
1) doing any extensive amount of work in a constructor is an anti-pattern
AFAIK.
2) If the API is designed so that I am expected
Ever heard of constructor chaining?
-Matej
On 11/3/07, Brill Pappin [EMAIL PROTECTED] wrote:
Moving to the list as suggested by Gwyn.
From Jira issue:
https://issues.apache.org/jira/browse/WICKET-1108
Maybe I wasn't clear on what my problem with it was.
1) doing any extensive amount of
Brill Pappin wrote:
Moving to the list as suggested by Gwyn.
From Jira issue:
https://issues.apache.org/jira/browse/WICKET-1108
Maybe I wasn't clear on what my problem with it was.
1) doing any extensive amount of work in a constructor is an anti-pattern
AFAIK.
Blindly declaring
On 11/3/07, Al Maw [EMAIL PROTECTED] wrote:
There's nothing to stop you making your constructor call methods to
initialise things that people can then override.
erm. really? while there is nothing stopping you, you clearly shouldnt...
-igor
On Saturday 03 November 2007 21:18:17 Brill Pappin wrote:
This is a common Java pattern. There should be only one place in the code
where properties are set from a constructor, all other constructors should
pass on their parameters, defaults if required, to the one constructor that
actually
IMHO it does make sense. When I see several different super(...) calls in
constructors the first thing that crosses my mind is that these superclass
constructors have different logic. But it's not true for wicket and in most
Component subclasses I can call super(id, (IModel)null). Can I?
Yep,
On 11/3/07, Dmitry Kandalov [EMAIL PROTECTED] wrote:
On Sunday 04 November 2007 01:23:39 Eelco Hillenius wrote:
IMHO it does make sense. When I see several different super(...) calls
in
constructors the first thing that crosses my mind is that these
superclass constructors have
Probably right.
In the example below, some may argue that the javadoc (here aimed at
sub-classers) on the parent class' constructor could say (as loudly as
possible, but probably never quite loudly enough) that doStuff() is called
before all state is fully initialised (in this case, eye is still
that sb:
final protected Eye getEye(){return eye;}
jweekend wrote:
Probably right.
In the example below, some may argue that the javadoc (here aimed at
sub-classers) on the parent class' constructor could say (as loudly as
possible, but probably never quite loudly enough) that
Yep, you could. Though some constructors in other classes (in or
outside Wicket) might expect not-null arguments passed in in
constructors. It just depends on who implemented it. There is no
golden pattern that everyone follows; if there was, it should probably
be enforced in the
On Sunday 04 November 2007 02:37:39 Johan Compagner wrote:
You just should call super of the same constructor you are in.
just give the super call everything you got. If you got a model, give it
but you don;t have to you can set it in the constructor with setModel
afterwards.
That's what I
11 matches
Mail list logo
