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

Reply via email to