Newsletter sign-up
View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Creating custom components

Learn how easy it is to create specialized components, reuse them, and keep your application-level code cleaner with internal event handling

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Many applications can work just fine with standard user interface elements supplied with the Java API. And when necessary, programmers can glue these elements together to create a more sophisticated interface. However, if a collection of supplied components are added and handled in order to achieve a higher-level user interface function -- a single conceptual user event like a font selector, for example -- the event handling can get extremely messy at the application level.

Let's take our example above and consider an application that needs a font selector. To add this functionality, we would need to use three separate components to gather the name, style, and point size of the font. The application's event-handling code would, of course, need to include filters for all three components. That's a whole lot of internal event handling to keep track of. If instead we created a distinct font selector component, this inherently internal event handling would be hidden. The application would only need to catch a font selector event object, and the target of the event would be the instantiated font selector object itself -- a much cleaner approach.

Clearly, an important feature of custom components is this ability to hide details from your application, but the decision to write custom components also should be driven by the reusability factor. When you find yourself in need of a particular functionality over and over again, it would make sense to create a custom component for this task. Taken one step further, you can combine specialized user interface elements that are used repeatedly into a custom component package, making the classes easy to reuse, especially among a group of developers.

Now, before you go writing customized code for every possible variation of a component, I must mention one caveat in regard to custom components. When you are developing applets, your custom component classes will have to be downloaded because they are not part of the core API available locally to all Java virtual machines. As long as your applet doesn't use a lot of custom classes, you've got nothing to worry about, but if optimal download time is critical, make sure you thoroughly consider the necessity of enhanced functionality.

Event handling in custom components

As I mentioned earlier, one really nice advantage of writing specialized components is that your application-level event handling will be much cleaner. The Component superclass has a method, postEvent, that you can use to propagate an event to the parent container. This Event object will contain all of the information that the container needs to determine the details of the event.

The Event object has several variables (target, arg, date, x, and y, among others) for determining such facts as which component generated the event and the time of the action. The arg variable is essentially the "message" of the event. This field is of type Object, which means that it can hold any type of information. The Checkbox class, for example, uses this field to store a boolean corresponding to the state of the checkbox, which allows it to notify the application of its new state. In terms of a font selector, the message this component needs to get to the application is the Font object chosen by the user.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources
  • Previous Step By Step articles