I am trying to learn java web programming. I come from a perl scripting background and know very little Java, much less JSF/Seam/EJB3.0. I’ve made a LOT of progress in this very steep learning curve, but there are some large conceptual issues that I think are hampering me a bit.
Lately I’ve turned my attention to learning JSF. Usually discussions of JSF include a description of component-based web programming, but seem to assume one has experience with the other paradigms of web programming. I would be interested to see a fuller discussion of this component-based paradigm in the context of other paradigms.
Can someone explain?
Thanks in advance for your thoughts.
TDR
The basic idea is just an extension of Object Oriented Design: Separate the concerns of your program. The same way you may make several different PERL scripts and string them together to do work, we will make several different JSF components and string them together to do work.
Let’s take a simple registration form as an example. I want to know your name, your birth date, your address and submit this all to the back end to do work.
First thing we need to do is break up your form into logical pieces. If we knew we were going to reuse this exact form in a lot of different places, maybe this form itself would be a logical piece. In which case we could create a component that would render this whole form and tie it to a bean like “Contact.” That way, any time you needed to use the form, you could dump it in, tie it to a Contact bean (the how would depend on your framework) and go from there. But that would make this a pretty dull example. 🙂
From my estimation I see name, birth date and address as three seperate, logical units. Name would probably be simple. Just a standard text input. So we can use a h:inputText element, or your framework’s prefered version, and tie that to your bean’s name field.
Second, we have the birth date. At its simplest, we can create a h:inputText field and add a f:converter element so that when we tie it to the bean, it will come out a date. You can scale this up to be a fully interactive calendar widget, complete with Java Script and what not. Check out IceFaces and RichFaces for some good examples. But the same core concept remains: A single component which you will tie to a date object.
Third, we have the address. This makes a great choice for a component, because likely you will need to know addresses in a lot of different pages. It’s also a lot more complex than a single input. You’ll need to combine multiple inputs, validations and fun ajaxy stuff to make a single cohesive unit. However, the developer who uses it will hopefully only need to do use
<foo:address value="#{BarBean.address}"/>with maybe a couple of other options.
This seperation of concerns is at the core of not only Component based web design but object oriented programming itself. There are plenty of tools to make this easier too! Facelets is a great example. You can seperate your basic layout into its own sheet, simply injecting the useful content via the ui:define elements. You can create composition components that allow you to quickly create more useful components without delving into the JSF component framework; the address example would be very simple to do with a Facelets composition component. IceFaces is another good example. It handles all sorts of AJAXy type inputs, redraws and updates without me having to worry about how it all works (for the most part. 😉 letting me focus on what the form is to accomplish, not how to accomplish the form.
This only scratches the surface but the broadest strokes are similar to any large program: Identify the smallest, logical pieces and build them before using those to build bigger pieces.