On Tue, 9 Nov 2010 11:33:31 -0500 James Carman <ja...@carmanconsulting.com> wrote:
> Say you have two forms on one panel (don't know if this is the best > example or not, but here goes). You want to move a field from one > panel to another. You'd have to do that in code with the traditional > approach. With the "queued" approach, you'd just queue all your > components to the parent container and it would auto-add them to the > correct subcomponent as it finds them in the markup. Are you moving a field from one form to another? But that does change the semantics, doesn't it? If it doesn't, why are there two forms? > With this, the order does matter, though. Suppose you had two > components you wanted to queue with the same id, completely different > components. If you reverse their order, then they're auto-added in a > different order. Ouch. I think this has the potential to be a showstopper. This will be an endless source of hard-to-find bugs. I think there needs to be a unique-id requirement when you start using queue. Right now we require unique-ids on the same hierarchy level, i.e. direct descendants of the same component. With queue, we're basically extending necessity that to the whole subtree. Carl-Eric www.wicketbuch.de --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org