I'm writing a chapter on creating custom components for Wicket In Action currently. We actually didn't even plan on making this a separate chapter – almost everything you do with Wicket results in creating custom components anyway -, but after some recent discussions on The Server Side and JavaLobby, I decided Wicket In Action really needs such a chapter.
What amazed me in these discussions is how being able to create custom components in an easy way was waved away as being of secondary importance. It's all back to EJB 1/2 with the idea that it's okay if it is harder to author custom components because they will be written by either third parties or by the senior coding gods of your company. The grunts just need an extensive library to work with, and be happy with that.
Wow. Imagine being told that you can use Java as your programming language, but at the same time being told not to create your own classes. You probably could get a long way with that. But think about the loss of elegance, creativity and expressiveness you would loose. To me the whole fun and usefulness of programming with 3GL is that I can create any data structure I want, and that I can model an API that matches the domain I'm programming for. I fail to understand why that has to be different for UI development, and Wicket proves it doesn't have to be so.
Let me state some problems I have with the idea that having a bunch of component libraries should suffice for us grunts.
- There is a fat chance such components and the libraries they are part of will be pretty bloated. You either have a lot of components that all have their own specialties, or you have fewer components with larger sets of configuration options.
- Having the mind set of primarily using components instead of creating your own specialized components does not encourage code reuse on a project level. In fact, it will encourage code duplication and copy ‘n paste behavior. If you have a table to display users on several pages, but on every page in a slightly different manner, you probably would use a third party table component and configure it will all the parameters from scratch.
- It will be rare that third party component libraries know about the domain of your applications. So, instead of having a component that understands what an ISBN code is, and that knows how to look it up using AJAX, you would have to configure the ISBN specific validation and program the client side AJAX part every time you have to put in such a field.
- If you can ‘customize’ components just by extending and combining them, you’ll have much more flexibility than any prefab component can ever give you.
- And even if you would mainly use third party component libraries it should never be an excuse for a framework for their components to be tedious to author. The easier it is to write them, the higher the quality of these components probably will be!
This list is not exhaustive, but gives you an idea of why I think you should not just blindly buy into the argument that framework X is good because it has big libraries of prefab components. 'But they have all the functionality you will ever need!' Yeah, right. I don't need that color select component. Just give me a framework that will let me develop one myself easily and elegantly if I ever need it.