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