second of all i asked you to not post any discussion of this to this thread, i really dont understand why this is so difficult. can you not follow simple directions? why do you add noise to what already is a busy thread? why should people who are interested in the outcome of this thread waste their time reading your off topic posts.
my better judgement tells me to ignore your replies and not add any noise myself. but i am affraid that course of action is too implicit for you to understand, so i am making it very explicit hoping that the noise can stop at this.
you are more then welcome to reply to this if you have anything further to say, but pelase do it in another thread.
thank you,
-Igor
On 2/15/06,
Gili <[EMAIL PROTECTED]> wrote:
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
