> as I understand the readme the queue method basically has only a slightly > different behavior compared to the add method in the way that it either adds > a component as a direct child to the parent or as a sub-child as defined in > the markup. So the markup is only used to determine the child's location > below a given (code controlled) parent. This means if you replace the > current add method with the behavior of the queue method, existing code will > still work and we would not have two separate ways to add components. That > sounds like a good solution. > > @Martin: please start arguing with the given arguments and stop moaning. > Thanks.
I would argue that it is not completely safe to _replace_ add method with queue method. As Igor pointed out before, we might want to define security boundaries: componentA must be inside componentB. Such code should be implemented either traditionally or otherwise the new way of adding components via queue must implement a security feature that allows restricting child components inside a certain parent component in a fluid but robust manner. Plain queue implementation, however, is a very good starting point to begin studying various ways of imposing security boundaries. ** Martin > > On 08.11.2010 17:28, Igor Vaynberg wrote: >> >> it is not about fixing something that isnt broken, its about making it >> easier. anyways, i just updated the readme in my experimental branch >> that explains the solution a bit more: >> https://github.com/ivaynberg/wicket/tree/component-queuing >> >> -igor >> >> On Mon, Nov 8, 2010 at 8:23 AM, Vitaly Tsaplin<vitaly.tsap...@gmail.com> >> wrote: >>>> >>>> I'm sorry to say, but the whole discussion makes little sense to me and >>>> these attempts to fix something that is not broken actually scares me a >>>> bit. >>> >>> +1 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org