A word about custom components

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.

  • It depends on the quality of the components. Do a search on the internet for ‘components’ in the broad sense. Look up calendars, rich editors and tree widgets for instance (or search for reusable EJBs if you're really in for a laugh). You will find a lot of these, but how many of them are really good? My experience with this is very disappointing, whether it concerns Java Applets, JavaScript widgets or JSF and .NET components, the quality is often quite below par. And the better components are often only commercial available, forcing you into extra bookkeeping, additional costs – usually not a lot, but for some components quite extravagant – and dependency on third parties (are you sure they will fix the issues you find rapidly?).
  • 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.

6 thoughts on “A word about custom components

  1. n8han says:

    You’ve found the source of that “liberating” feeling we all get from Wicket programming. Funny that programmers writing their own components is such a radical idea.

    When I started my first Wicket prototype I was told that Wicket would never be able to compete with JSF’s commercial component libraries. Into my mind flashed an array of crappy pre-fabs designed to appeal to everyone’s non-techie boss (“This one looks just like Excel!”) and my response was, “Huh?”

    Your response is a lot more eloquent.

  2. chillenious says:

    Actually, my response is just a fancy way of saying ‘Huh?’ or even ‘WTF?’. ;)

  3. middledot says:

    Big companies have the resources to spend on specialised components as long as the job gets done quickly. In a long run they have saved a lot of buck.
    Most creativity (usually) comes from smaller teams and small companies unable to spend extra money on the ready-made components and that’s why they create them themselves.
    If a framework provides ready made components and allows you to easily create new ones then that framework has what it takes to be a winner. And guess what it’s Wicket!!!

  4. chillenious says:

    I think even for large companies it makes sense to ‘think in custom components’. They typically have more rigid rules when it comes to complience to company’s (UI) standards etc, and if such a company does a lot of projects, there will even be many opportunities to reuse domain specific components across projects.

    But yeah, smaller companies should definitively try to be independend from third parties. Though if the offering of a certain component lib is really good, it can save time, money and marriages. The point of my piece here is that the availability of commercial component libraries is used often as the main sales argument for a couple of famous frameworks, while I think that is largely a bogus argument.

  5. Frank Silbermann says:

    I just implemented a system with about 50 pages, each of which displays the results of a different SQL SELECT query customized by parameters set by the user. Some pages provided multiple such panels. Each result set display was associated with a button so the user could download the table as a file readable by MS Excel.

    Does any commercially available component set provide a result-set display component with an associated button for downloading contents as an MS Excel file? Of course not! That would be too ad-hoc a requirement.

    Yet, the thought of re-writing HTML to display both a result-set and a download button, and the Java code to populate the display both in the table and in response to the MS Excel request buttons click _50+_ times was sickening! Wicket saved me.

    Yes, if it is truly essential, most frameworks will (with severe difficulty) allow gurus create their own compound components. But the difficulty inhibits refactoring, so you’re design had better be perfect the first time.

    The move towards object-oriented programming languages in the 1990s was motivated by real productivity needs, and it seems silly to pretend that we don’t have the same productivity needs when coding presentation logic as we do when coding business logic.

  6. […] posted almost a year ago about how important it is that components are easy to write in Wicket, and how […]

Comments are closed.


Get every new post delivered to your Inbox.

%d bloggers like this: