No that is not possible.
Consider:
add(new WebMarkupContainer("foo").add(new Label("bar", "bar")));
add(new WebMarkupContainer("bar").add(new Label("bar", "bar")));
How could Wicket automatically know where to add the nested bar? Is it
a child of foo or of bar? or isn't it a child?
Martijn
Considering that the hierarchy is specified in the template, isn't there
some way to use this to construct the hierarchy automatically?
Robert
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techs
IModels and
>> so on, as I think this would make the code a lot more readable.
>>
>> Well, just my 2 cents here :)
>>
>>
>> Rüdiger
>>
>> Dipu schrieb:
>>> We are still using 1.2.1 and 1.2.5 for our production and near
production
>>> proj
here :)
>>
>>
>> Rüdiger
>>
>> Dipu schrieb:
>>> We are still using 1.2.1 and 1.2.5 for our production and near production
>>> projects.
>>>
>>>
>>> Thanks
>>> Dipu
>>>
>>>
>>> ---
my point is that we are a framework and we already provide what is needed to
make this and the entire superset of these kinds of things possible. our job
is to provide functionality needed for 90% of usecases and leave the other
10% possible. this falls into the 10%.
-igor
On 3/8/07, cowwoc <[E
The point *was* that onWire should get called whenever the parent
changes (i.e. when moving a component to another parent). If one wishes
to listen for hierarchy changes one could implement some event listener
mechanism to that effect by overriding onWire() of the ancestor nodes
and have t
what happens when you move the component to another parent? will onWire be
called again? and if not can we have a method that will please? and then
another method if the component's hierarchy changes - a components ancestor
is moved.
point being only a small percentage of wicket components care a
That's why I used the terminology onWire() as opposed to onAdd(). My
point was that you should shift the burden of isInitialized() away from
the end-user over to Wicket. When a component's ancestors (all the way
up to the top-most component) are connected the first time or changed at
some
this wont work.
-igor
On 3/8/07, cowwoc <[EMAIL PROTECTED]> wrote:
How about a hybrid system?
Is there a clear-cut way to know up-front which components have an
immutable parent versus others that might require it to change during
rendering time? If so, couldn't you require
The problem with that is that the 2.0 constructor actually forced the
whole parent hierarchy to be in place, while add in 1.x just means it
is added to the parent without any guarantee the parent is added to
the parent yet. So even if we would provide onWire (though onAdd would
be better then) it w
Alternatively:
1) Components are POJOs. Users can define whatever constructor they want.
2) Users always use add() to associate a parent with a component but you
move the component wiring out of the constructor and into a onWire()
method. Now, whenever the hierarchy/parent changes onWire
> How about a hybrid system?
>
> Is there a clear-cut way to know up-front which components have an
> immutable parent versus others that might require it to change during
> rendering time? If so, couldn't you require the use of constructors that
> take a parent for components whose
How about a hybrid system?
Is there a clear-cut way to know up-front which components have an
immutable parent versus others that might require it to change during
rendering time? If so, couldn't you require the use of constructors that
take a parent for components whose parents a
;
> Rüdiger
>
> Dipu schrieb:
>> We are still using 1.2.1 and 1.2.5 for our production and near production
>> projects.
>>
>>
>> Thanks
>> Dipu
>>
>>
>> - Original Message -----
>> From: "Eelco Hillenius" <[EMA
... and having two active development branches seems like a really bad
idea. /Anders
Anders Peterson wrote:
> I don't care about (understand) the pros and cons regarding the
> constructor change. What Wicket needs is parameterized models
> (generics). I think you should do what ever it takes t
I don't care about (understand) the pros and cons regarding the
constructor change. What Wicket needs is parameterized models
(generics). I think you should do what ever it takes to support this in
a released version as soon as possible.
/Anders
Gabor Szokoli wrote:
> On 3/7/07, Korbinian Bach
"Eelco Hillenius" <[EMAIL PROTECTED]>
> To: "Wicket User List"
> Sent: Tuesday, March 06, 2007 10:12 PM
> Subject: [Wicket-user] IMPORTANT: your opinion on the constructor change
> in2.0
>
>
>> Hi,
>>
>> We (Wicket's developers) are
On 3/7/07, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> Also please if you decide to not use the new constructor go on a JDK1.5 solo
> dev path soon
+1 for this if I understand it right :-)
We are not committed to either version yet, do basic prototypes in
1.2, but untyped getModel() is getting o
> [mailto:[EMAIL PROTECTED] Im Auftrag
> von Eelco Hillenius
> Gesendet: Dienstag, 6. März 2007 23:13
> An: Wicket User List
> Betreff: [Wicket-user] IMPORTANT: your opinion on the
> constructor change in2.0
>
> Hi,
>
> We (Wicket's developers) are having some discu
Same here, 1.2.3 and 1.2.5 based projects in production, quite large
codebase, no intention to go to 2.0 until it finalizes.
--
János Cserép - [EMAIL PROTECTED]
Web: http://www.szeretgom.hu
Skype: cserepj
-
Take Surveys. Earn
We are still using 1.2.1 and 1.2.5 for our production and near production
projects.
Thanks
Dipu
- Original Message -
From: "Eelco Hillenius" <[EMAIL PROTECTED]>
To: "Wicket User List"
Sent: Tuesday, March 06, 2007 10:12 PM
Subject: [Wicket-user] IMPO
21 matches
Mail list logo
