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

2) an exception thrown from a constructor will prevent the object from being created (security)

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.

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.

5) constructors, as the name implies, are used for constructing things in java.

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.

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.

-Igor



On 2/14/06, Gili < [EMAIL PROTECTED]> wrote:

        Instead of introducing extra arguments to the constructor, why not
simply move all this logic into a new method?

        That is, introduce Component.bind(Component parent). We'd benefit from
the fact that Wicket components could become JavaBeans and method-based
binding is more flexible than constructor-based binding.

        From past experience, whenever classes require arguments in their
constructors there is always some flexibility lost. For example, you
absolutely cannot invoke any code before super() if you subclass such a
class so if the value of one of the arguments needs to be calculated or
modified in any way prior to the super() call you're out of luck.

Gili

Timo Stamm wrote:
> Johan Compagner schrieb:
>> that would be very hard to maintain.
>> For example if you have a panel that is rewritten by using only the new
>> parent in constructor params.
>> And you add that in youre own webpage/panel that doesn't use that
>> parent in
>> constructor param.
>> Then you get all kind of errors because the child panel expect to have it
>> all but because of the hierarchy problem
>> that we have then, he doesn't have it.
>>
>> So i do think it is all or nothing.
>
> I see, thanks for the explanation.
>
> -1 for constructor change.
>
>
>
>> On 2/14/06, Timo Stamm < [EMAIL PROTECTED]> wrote:
>>> Martijn Dashorst schrieb:
>>>>  - constructor refactor
>>> Wow, that's a /major/ change and will probably effect every custom
>>> component and every application written using Wicket.
>>>
>>> I see the benefit of having a complete component hierarchy availably
>>> right at the initialization of a class.
>>>
>>> But wouldn't it suffice to just make the new constructors available, and
>>> put a clear statement in the API docs? Then maybe deprecate the public
>>> add() in the next major version, and drop it in 2.0 or something like
>>> that?
>>>
>>>
>>>>         This opens up a lot of better markup parsing strategies for the
>>>>         core.
>>> Just get rid of markup, it sucks anyway ;)
>>>
>>>
>>>>  - java 5 support
>>> +1
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> 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
>>>
>>
>
>
>
> -------------------------------------------------------
> 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
>

--
http://www.desktopbeautifier.com/


-------------------------------------------------------
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

Reply via email to