On Tue, Nov 9, 2010 at 8:10 AM, Carl-Eric Menzel <cmen...@wicketbuch.de> wrote:
> On Tue, 9 Nov 2010 10:51:49 -0500
> James Carman <ja...@carmanconsulting.com> wrote:
>
>> On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann
>> <frank.silberm...@fedex.com> wrote:
>> > If the component hierarchy can be changed without changing behavior
>> > or semantics, then why are the components in a hierarchy to begin
>> > with? Why aren't all the components being moved around already
>> > siblings at the same level?  Does Wicket require that the order of
>> > sibling Wicket components match the order at which simply HTML
>> > elements appear?
>> >
>>
>> You could do that, but I think Martin is trying to take it a step
>> further allowing you to have an arbitrary hierarchy in your markup and
>> just figure it out at runtime.  Wicket doesn't care what order you add
>> stuff to the page/component as long as they're all on the same level
>> within the hierarchy.
>
> I think you misunderstood Frank's point. Why are the components in a
> hierarchy in the first place, if the hierarchy can be changed without
> changing behavior or semantics? They can simply be flat in the parent
> then.

sadly there are valid usecases for having the hierarchy purely for
design purposes. an easy example is:

<tr wicket:id="repeater"><td><span wicket:id="first"/> <span
wicket:id="last"/></td></tr>

now the designer wants tds to have a css class based on some
condition. you now have to add a webmarkupcontainer to represent the
td and renest first and last labels into it. the container is there
purely for the design aspect.

with queuing you can queue first and last under the repeater item.
when you need to add css to td you simply queue the webmarkupcontainer
under the repeater item as well and wicket will properly nest the
labels in it for you.

another usecase is introducing an arbitrary webmarkupcontainer just to
have a div to repaint via ajax. it is hard to do this when refactoring
a complex page because you have to find all the components that now
need to be re-nested into the new container.

hopefully queuing can eliminate some of this noise and make it easier.

-igor

>
> Carl-Eric
> www.wicketbuch.de
>
> ---------------------------------------------------------------------
> 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

Reply via email to