Wherefore Art Thou, Oh Components
By craigmcc on Oct 02, 2004
In a TheServerSide thread responding to the fact that I've started blogging, an interesting question came up from a reader with the alias
While the first part of this statement can lead to its own set of interesting design discussions (on "one big component" versus "assemble complex things out of simple things"), let's focus here on the second part. I believe that, in the case of JSF components, there will be more than one answer to this question over time. Let's look at some of the possibilities, using the term widget as a generic reference to some sort of reusable user interface component that is written against some sort of API supporting component development.
- First, consider a complicated widget from your favorite UI technology (say, Struts Layout;
Table, or whatever). Did a page author create the implementation of these widgets? Probably not; it was likely a Java developer either working on the framework itself, or intimately familiar with the APIs of that framework, who created something reusable. The Java developer undoubtedly used their own favorite editor or IDE (insert gratuitous "Emacs rules, Vi drools" discussion here :-).
- A second traditional source of widgets has been the providers of IDE tools themselves. In order to enhance the design time experience of the page author, the tool will often provide prebuilt widgets with extra design time support (for example, GUI dialogs to configure the columns in a table, or data binding dialogs to attach to model tier business objects). Traditionally, the components provided by a tool would typically conform only to the component API supported by that tool. One of the ways that JSF encourages more components is making it possible for these same components to be used in other tools as well. See, for example, what Oracle is doing to migrate their traditional (Oracle proprietary) components to JSF with ADF Faces.
- Naturally, the open source community has been a historical source of widget libraries for various component APIs. Previously, such libraries have tended to be closely associated with the underlying component API project (or its development community); the advent of a standard component API makes it much more reasonable to build such libraries that plug in to multiple frameworks or tools.
- Page authors, in my experience, are generally less concerned about creating "fine grained" reusable chunks of markup (although they do like the idea of being able to reuse such chunks created by others). JSP, for example, has evolved ways to reuse fragments (such as static and dynamic includes in JSP 1.0, or tag files in JSP 2.0). My belief is that these technologies will continue to be leveraged for larger chunks of stuff (such as a banner that is common across multiple pages), rather than on individual widgets, and we'll see tools focus on supporting this sort of use case (for example, see Page Fragments in Sun Java Studio Creator). On the other hand, it's certainly feasible to contemplate a specialized tool for building JSF components that starts with a chunk of markup, and creates the component classes for you -- it's just fairly straightforward Java code, after all.
- Finally, there are generally "standard" components provided by whatever component API you are using.
In the case of JSF, this is the set of simple HTML components that are provided out of the box, so
you can at least become familiar with the technology quickly. This is where commonly required
concepts show up to be standardized (analogous to the way that JSTL standardized tags like
<c:if>that every tag library needed, but everyone was doing differently). This is not where you are going to see high speed innovation in fancy new widgets. And that is a Good Thing (tm). The focus is, and continues to be, on a high quality API underlying the components that are, and are becoming, available from the sources listed above.
So, where do reusable components come from? The same places that they always have. The extras that JSF provides (a common basic API for building such widgets, useful infrastructure like managed beans and value bindings, and an architecture designed to be easy to support in tools) encourages the development of component libraries that are not aligned with only one technology or tool -- the focus is as much on reusable as it is on components.