> ...and that makes the queue method a candidate to replace the add method > without breaking anything.
Yes :) ** Martin > > > 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
