Lately I've done some wicket development. Let me first say I don't consider me as a wicket guru at all, well not yet ;)
Wicket is a perfect example of Directing Attitude as explain by martin Fowler in SoftwareDevelopmentAttitude, from the wicket documentation "why-final":
Just like martin Fowler, I more of an "enabler" type of guy:
While this defensive approach may seem obsessive to some, the major benefit is that classes and methods which haven't been designed for extension cannot be extended until the problem(s) at hand are examined by the Wicket development team.
Just like martin Fowler, I more of an "enabler" type of guy:
(...) Such an argument is much more convincing to me that the usual one which carries the subtext that library writers are smart and users stupid.
I'm also concern about the "fragile base class problem" since everything in wicket use inheritance. But in this case, I think the "Directive Attitude" may leverage this problem...
In the future I see 2 possible evolutions directions for wicket (just like any framework):
- No more major evolutions to avoid existing code to be broken (this may sometimes lead to a fork of the project)
- Major evolutions between major releases (when changing the first digit of version number for example), this may lead to unhappy / unable to follow wicket evolutions users... and just like with Howard Lewis Ship from tapestry that leads to angry comments on blogs, web sites:
Every major point release of Tapestry throws backwards-compatibility out the window.
All those issues are not wicket specific problems but more frameworks common problems and there are no simple solutions, those guys need to keep developers and users happy at the same time and That is a big challenge !
