Wherefore Art Thou, Oh Components

In a TheServerSide thread responding to the fact that I've started blogging, an interesting question came up from a reader with the alias NullPtr:

I am speaking about building a custom JSF component. A custom JSF component can comprise (sic) of several sub-components arranged in a specific layout, there could be JavaScript associated with these components. Who writes this component, the Java developer or the web designer, and how?

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; Tapestry's contrib:Table, Echo's 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.
  • Within large corporations, it is common to see the Marketing Department (for external facing applications) and/or the IT department (for internal apps) mandating that all applications conform to a common set of look and feel standards. For example, I was visiting a customer recently that had a prebuilt set of JavaScript code to create menus with a common look and feel across all of the pages. Currently, that means each page author starts with a cut-n-paste of template code in order to create every new page. A great strategy would be for the IT department to package up that JavaScript code into a widget (this is very easy to do with JSF components) so that the page author can leverage the drag and drop capabilities of development tools to add the code block to their page, and (perhaps more importantly) customize its behavior using property sheets, just like you can customize the characteristics of an Input Text component.
  • 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.


I think that JSF components have to come from Open Source initiatives... They have to be free or JSF will not gain traction (I will continue using Tapestry or Echo). JSF can benefit greatly from Tapestry and Echo... analysis of either will point out the most important components and the weaknesses of the implementations. For example, when you see postings every day on how to use a component, you can bet that the API could use some help.

Posted by John on October 12, 2004 at 11:54 PM PDT #

>I think that JSF components have to come from Open Source initiatives How they (components developers) will earn in this case?

Posted by Dmitry on October 15, 2004 at 07:31 AM PDT #

Hi Craig, I am trying to understand how JSF decided on a JavaScript based model. It appears a JSF-based site will be unusable if JavaScript is turned off. Accessibility organisations such as the National Federation for the Blind (nfb.org) clearly state that: "Pages which rely on JavaScript are not accessible to blind people using text-only browsers". JSF therefore violates e-government accessibility laws. No government organisation and a broad range of corporations will be barred from using JSF. The UK government for example requires web sites to work correctly "with browsers that do not support client-side scripting at all or that have client-side scripting turned off". Is there something I am missing here? If not JSF looks like a non-starter from the outset. Rohan

Posted by Rohan on November 02, 2004 at 11:51 PM PST #

Post a Comment:
Comments are closed for this entry.



« December 2016