On Mon, Nov 8, 2010 at 8:58 AM, Martin Makundi <martin.maku...@koodaripalvelut.com> wrote: >> 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.
thats exactly what it does, as my readme file explains in the git branch... -igor > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
