Hi!
> its not about the list *items* its about the components you add to them
>
> onpopuateitem(item item) {
> add(new label("name"));
> add(new label("email"));
> }
>
> wont work
Why should it? Won't make it any easier than:
item.add(new label("name"));
item.add(new label("email"));
>> The developer can choose: using unique wicket:ids or traditional ones.
>
> i would not want to support both approaches. it will make things very
> difficult for us and for developers. we should have one consistent
> approach.
Thank god nobody said "640k will be enough for everybody".
Why is there private, friendly, package and public visibility
confusing java developers?
What about giving more freedom to design effectively according to
designer's choice?
> you say its "hell" but let me remind you that you are in a
> very very vast minority about this. how many threads on this list are
> about this hell compared to other threads? not many at all, not even
> 1%. therefore, im not too inclined to change the way the entire
> framework works for the loud 1%.
I believe most are just acustomed to using it as it is. Even more
people are accustomed using JSF.
That feels more like an excuse to refrain from making Wicket even better.
>>> 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.
>
> redundant for basic cases, yes. not redundant as soon as you are
> trying to do something non-trivial. you cant build anything
> interesting if you only try to use trivial constructs.
Web pages are 80% trivial. Small friction like doing unnecessary
hierarcy matching is waste of time. 5 min per hour, 40 minutes per
day, 800 minutes per month, 20 people team 16000 wasted minutes per
month is 33 days per month wasted only because of wicket hierarchies.
**
Martin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
