Then we still don't have the parent (==page) already available in the constructor.
And what does that last part (flexibility lost) have to do with adding a parent in the constructor
You just have to pass that thing through nothing more.
johan
On 2/15/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
