>> Duh.. I think there can be _no_ excuse to not reduce manual work where
>> it is really not needed. It's not like we are talking about airline
>> autopilots here.
> So we don't need Wicket to work predictably and reliably all the time?

We are only proposing a new way of doing things faster with equal
reliability or even better if piggybacked with compile time safety.

> I see cases where folks in this thread have identified areas
> where your proposal *could* work *much of the time*, I am
> 100% concerned about total cost of ownership, which is
> directly linked to maintainability.

How do you see this explicitly affecting total cost of ownership?
Wicket internal component path structure would not change a single
bit. Only difference is that developer does not need to write code
according to html hierarchy - instead wicket will deduche hierarchy
from HTML. Total cost of ownership should be lower because of more
efficient ways to produce new software.

> As a dev, I really don't have a problem with assigning id attributes.
> Putting on my stakeholder hat, I don't care if my developers have to
> type "wi<ctrl><space>"

This is not what the proposal is about. It's a proposal not to be
obliged to nest components in java because they are already instructed
to nest according to HTML. Simply leave out redundant bytecode

> Wicket is open source though.  Start a branch and prove your theory works!  
> :-)

We will provide a patch if possible. However, we might need some help
onto our endevor.



To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to