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