Replies below...
Igor Vaynberg wrote:
we have considered both options when figuring out the solution. we
called it init() instead of bind() but it was basically the same thing.
here are some advantages of a constructor over an init() method:
1) constructors are atomic
Wicket components have always been thread-unsafe by design, so I fail
to see how this is relevant. Do you plan on sharing Wicket components
across threads anytime soon? Just define Component.isInit() and set it
to true if a component has been initialized, and prevent
double-initialization.
2) an exception thrown from a constructor will prevent the object from
being created (security)
Correct me if I'm wrong (you probably know more about this issue than
me) but isn't the real security concern whether or not the Component may
be rendered as opposed to whether or not it may be constructed? For
example, normal users do not have admin access, so they should not be
able to visit admin-only WebPages. You could enforce this security check
at render time.
3) constructor parameters are much easier to pass. if you have a
parameter that you want to pass from a constructor you would have to
store it as a field so it is available in init(), this makes things
really really dirty and break encapsulation.
I think that is subjective. All JavaBeans work this way (if you need to
use a variable later on, you are forced to store it as a field) but this
has never bothered me. I already do this kind of thing with Wicket when
I need a variable at render time (this happens quite often). In my view,
this is no more ugly.
4) constructors insure the proper order of creation. you cant have
things like. Panel p1=new Panel(); p2=new Panel(); p2.init(p1) <== error
because p1 hasnt been initted and bound to the page yet.
The situation you describe exists with the current implementation (i.e.
this is nothing new). IMHO this is common sense. I don't think anyone
would find it confusing.
5) constructors, as the name implies, are used for constructing things
in java.
Right, but we're not constructing, we're binding. A WebPage floating in
space is just fine. You should be able to use a constructor to create
such an instance. Using Swing as an example (since Wicket is based upon
it), you often create a component using a constructor and bind it using
add() or setParent().
6) constructors give component creators the ability to use the good
citizen pattern
so in the end using construcors leads to a much more concise and clear
code both for component creators and component users.
also saying things vague like "its better because components can be
javabeans" doesnt mean much. why not give arguments as to /why/ it would
be better to have components as javabeans.
For one, many frameworks play very nicely with JavaBeans. If Wicket
components were beans we could seamlessly plug them into things like
XMLEncoder and the various bean APIs that manipulate them.
anyways, this is not what this thread was about. if anyone is interested
in discussing any of the points above please start a different thread.
This discussion is regarding whether or not we should be passing the
parent into the constructor as opposed to the current add() mechanism. I
would argue that the current discussion is quite relevant in that we are
trying to give our feedback on this proposal. I'm not arguing against
the existence of constructors just for the sake of argument.
Gili
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
