Hi!
> what bothers me about this is that it wont work for everything. for
> example, it wont work for repeaters:
> these are just the two that come up off the top of my head.
What do you mean? Repeaters have unique index, it's not a duplicate.
public ListItem(final int index, final IModel<T> model)
{
super(Integer.toString(index).intern(), model);
this.index = index;
}
> such helpers will no longer be possible because we have forced the
> panel to have unique wicket ids
The developer can choose: using unique wicket:ids or traditional ones.
> what has always attracted me to wicket is its consistency. once you
> learn how to add components you can use the same method for all
> usecases and it works. it seems like this would take away from that.
It is consistent yes, but also redundant.
> Keeping the two hierarchies in sync is not really that difficult.
> I just really don't see the benefit in this. I've taught tons of people
> Wicket, and keeping the hierarchy in sync is hardly ever the
> thing that makes it difficult for people to learn or use.
It is not about being difficult, it's all about being efficient.
Redundancy is waste. Waste is bad. "Intentional waste" is even worse.
So let's lean it out ;]
**
Martin
>
> On Thu, Nov 4, 2010 at 1:13 PM, Martin Makundi
> <martin.maku...@koodaripalvelut.com> wrote:
>> I propose "Free Wicket" from component-hierarchy hell
>>
>> We have discussd before that Wicket has unnecessary binding to
>> wicket:id and component hierarchy
>> [http://www.mail-archive.com/users@wicket.apache.org/msg53941.html].
>>
>> I think I found a simple solution: "wicket:id" should be allowed to be
>> on any level within given Panel-type element. User has freedom to
>> position components and change html layout.
>>
>> What you think?
>>
>> Old wicket applications can be automatically refectored to have unique
>> ids. Currently the wicket hardcoded component hierarchy slows down
>> development and is totally unnecessary.
>>
>> https://cwiki.apache.org/confluence/display/WICKET/Wicket+1.5+Wish+List
>>
>> **
>> Martin
>>
>> ---------------------------------------------------------------------
>> 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
