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 !
2 comments:
Those two types, enabling and directing (note that 'enabling' has a more positive connotation to start with) are a bit too simplistic. Designing software like the 'directing' person would do, is not just about 'protecting' users, but also in large about protecting ourselves. More importantly, it is about trying to be clear about what the API is you provide. It's like designing a remote control with just a few buttons, so that it's use will be obvious.
Anyway, there is a road in the middle, and certainly now that Wicket matures, we're trying to loosen up where it makes sense, while still providing an API that is concise.
""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've always thought about this exactly the opposite way. The subtext of my own "attitude" (and I think Wicket's) is that /unquestionably/ our users are collectively smarter than the core team, and with a fully open API they will inevitably find uses for things that nobody on the core team ever imagined. Unfortunately, the results of that are often not benign to the framework or its community, which means measures have to be taken to prevent uncontrolled usage. In other words, API restrictions in Wicket are there to prevent /the core developers/ from screwing things up, not the users. -- Jonathan
Post a Comment