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 things anti-patterns with no real rationale is dangerous.
Constructors are designed to ensure that your object is completely
initialised and ready for use. If your page doesn't have all its
components added, then it's not initialised and ready for use.
Therefore, I think putting all that logic in there is a perfectly valid
place for it.
There's nothing to stop you making your constructor call methods to
initialise things that people can then override. Generally you won't
want to make/let people completely override everything, so you need to
put some thought into this. If you do want this, then just use a blank
super constructor and you're done (you can then sit back and watch your
users hate you).
2) If the API is designed so that I am expected to build a complex component
in it's constructor then I should be able to override any of the
constructors and expect it to be called.
But, err, you can't override constructors. So if you're writing the API,
call overridable methods from your constructor. I don't understand what
you're doing discussing this on the Wicket user list - this is just
basic Java.
If you don't want to include a specialized method for initializing a
component (e.g. the way Servlet works) and expect the constructor to be the
"primary" means of building up the component, then the constructors should
follow good practice and all get called.
Errr, what? We don't get a choice here - this is all governed by the
language itself. I think you might be confused about how constructor
chaining works. Either that, or you're completely failing to make
yourself understood properly.
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 sets the properties.
This is nonsense. You write code to achieve what you want it to in the
most concise and simple way possible.
If that means a single constructor which actually does stuff with a
bunch of other constructors that delegate to it with default arguments,
then fine.
If it means you have a commonInit() method that all your constructors
call, then fine.
If that means you have a bunch of constructors that do different things,
then fine.
If you don't code well, you have three immediate problems which as an agile
fan, I would cringe at:
1) You have duplicate code, no way around it.
2) you can never be certain which constructor is called by the API and any
given point. You may be able to get it to work, but a future change to the
API could break your code, and you might well not catch it with your own
unit test (you have some right?).
Again; errr, what? No offense, but if you can't work out which
constructor is being called for a given bit of code, you probably
shouldn't be writing Java for a living.
Future API changes can always break your code. I don't see how that's
relevant specifically to constructors as opposed to anything else. If
someone changes the API and your unit test doesn't pick it up, your unit
tests are very obviously broken. Changing constructors is really no
different to changing other method signatures, with the possible
exception that you're slightly more likely to be doing reflection on
constructors than methods (although with the prevalence of Hibernate's
HQL and Wicket's PropertyModels even that is arguable).
3) in order to support having two overridden constructors, I now am *forced*
to duplicate my own code (granted it could be one line, but its still
duplication).
Errr, why?
Now... fixing the constructor calls is not impossible but may require a bit
of thought (I don't believe thinking is a problem for the developers of
Wicket as they have clearly done a lot of it already) however I personally
would prefer a specific method call for initializing the component... at the
very least so I don't have to do all that work in the constructor, but it
also has the benefit of being *very* easy to implement with the current
codebase.
Despite my preference for an init override, I think the correct thing to do
with or without it is to fix the constructor calls.
Fix them how? I still don't even remotely understand why you think
they're broken. I'm not being deliberately obtuse, defensive or
belligerent. I've read the original bug report. I just genuinely don't
understand where you're coming from.
What is to stop you going:
public BasePage() {
commonInit();
}
public BasePage(IModel model) {
super(model);
commonInit();
}
private void commonInit() {
add(new Label("myid1", "foo"));
}
?
Regards,
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
