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! :-) Brian --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
