On Mon, Nov 8, 2010 at 9:07 AM, Sebastian <nospam...@gmx.net> wrote: > ...and that makes the queue method a candidate to replace the add method > without breaking anything.
not necessarily. while add() adds right away, queue holds componets in a buffer until after the oninitialize() cascade. so calling getparent() or walking the hieararchy cannot be done until after oninitialize() has been called on the parent container. this gives you no way to traverse and tweak the child hiearachy. i might move the code so it creates the hierarchy just before the parent's oninitialize(), post seemed safer at first glance. -igor > > Regards, > > Seb > > On 08.11.2010 18:03, Igor Vaynberg wrote: >> >> 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 >> >> > > > > --------------------------------------------------------------------- > 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
