It seems to me that most descriptions of Wicket that I've seen on the web focus on two properties:  the absence of configuration files and the radical separation of HTML from Java code.  (Then readers debate whether the absence of configuration files limit flexibility and whether the use of standard tool-friendly HTML is all that important.)
It seems to me that Wicket evangelists should put more effort on Wicket's object orientation.  The key questions we should ask when comparing Wicket to another component-oriented framework (e.g. Tapestry or JSF) are the following:
(1) If the user wishes to create a panel that assembles visual components or sub-panels that react to each others events, and which provide/handle events to be hooked to other arbitrary components on the page, what facility does your framework provide to package such an assembly in a re-usable format?
(2) If I have a complex, feature-rich component that I want to use on many web-pages, and some of the configuration choices will be set the same way for all of them, what facility does your framework give me for creating a facade around this component that will set these defaults for me -- so I don't have to repeat myself on page after page?
(3) If some of the pages which use this component need it to provide extra enhanced or specialized behavior, how does your framework make it easy for me to create a new component that extends the properties and behavior of the base component?
We should identify a few simple examples of such uses to contrast Wicket's power with other frameworks' shortcomings.  After the big-deal object-orientation revolution of the late-1980s/early-1990s, it astounds me that so many programmers can ignore the importance of object-orientation for coding presentation logic.
Take Surveys. Earn Cash. Influence the Future of IT
Join's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
Wicket-user mailing list

Reply via email to