It makes more sense to be before. I think the component hierarchy should be ready for onInitialize()
On Mon, 2010-11-08 at 09:32 -0800, Igor Vaynberg wrote: > 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 >
