On Fri, Nov 5, 2010 at 11:39 AM, Martin Makundi
<martin.maku...@koodaripalvelut.com> wrote:
> 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"))
right. this is the inconsistency i was talking about. sometimes you
use straight add() and everything works, but sometimes you have to add
to the proper component. this is going to cause headaches.
>>> 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".
thank god no one spent millions of dollars designing IEEE1394 to
compete against PCI and USB, otherwise it wouldve been a tremendous
waste.
> Why is there private, friendly, package and public visibility
> confusing java developers?
because without it you wouldnt be able to control visibility. your
proposal does not add any *new* features.
> What about giving more freedom to design effectively according to
> designer's choice?
because the designer delivers only part of the solution - the markup.
the missing part is the behavior and to think that the behavior can be
added in a completely orthogonal manner is foolish because behavior
and markup are tightly coupled on matter whichever way you slice it.
the best we can do is to make the coupling as easy and us unobtrusive
as possible.
the designers are free to move pieces around as long as they do not
cross wicket:id border, after all those borders are there for a reason
- to attach some behavior.
a very simple example is that you have a container that should only be
visible to admins of the application - this container contains
sensitive fields that normal users should not see.
<div wicket:id="for-admins-only">
<div wicket:id="salary"></div>
<!-- a bunch of other components -->
</div>
now the developer takes the "salary" div and moves it out of the
"for-admins-only" div. guess what, your *designer* has just opened a
huge security hole in your application. who would use wicket if such
things were so easily possible?
>> 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.
that is why we have no improvement and new feature requests in jira?
because everyone is ok with the status quo? is it also the reason why
we have not added anything new from 1.0 to 1.5, these have all been
bug fix releases?
>>>> 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.
and as with many such things we have to calculate if eliminating
redundancy is worth decreasing consistency.
>> 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.
if your web pages are trivial then why do you have hierarchy? you don
thave to have hierarchy in java just because it is in markup...you
dont have to model every single tag in wicket.
anywho, i think the fact that no one has really jumped in and sided
with you is a good indication where this is going.
-igor
>
> **
> 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
