On Nov 5, 2010, at 3:01 PM, Martin Makundi wrote:

> 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?  

MTBF is a composite factor of all weaknesses, what happens when the next weak 
hacks are added?  MTBF goes down exponentially.  Do Not Want.

As a dev, I really don't have a problem with assigning id attributes.  And 
while 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.  

Putting on my stakeholder hat, I don't care if my developers have to type 
"wi<ctrl><space>" a thousand times if it means the code cannot be blindly 
refactored in the future by people who are completely unfamiliar with how the 
original code was written.  Do Not Want. 

You might want to do some research on a version that was once considered 
"Wicket 2.0".  It was a valiant effort by everyone involved, but eventually was 
one of those paths that had too much risk and did not end well.  It wasn't just 
a problem for the framework developers (who also need to put bread on their 
families tables at the end of the day), but also for users who started coding 
to it and had to significantly refactor their applications when it ultimately 
didn't work.  

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

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

Reply via email to