So, I think there are two paths to that question. There's XForms versus Java and XForms versus Javascript. So let's think about XForms versus Java: Basically, the question typically is, "How much do I need to do in a round trip and go back to my JSP and do it there?" versus "What can I put in as events in the XForms document and handle it down at the client?" Generally, XForms is great at doing things like data validation, data filtering, fairly simple things. Actually, none of the stuff that you could theoretically do with Javascript on the client. That's typically what you're are going to farm out to the XForms document and those events.

What you're not going to want to do there are things that are really tied in with some of your business rules, some of your database rules, things that may change and be very, very volatile. You're definitely not going to want to put that in; you can't really handle them with your XFroms events. You not going to want to build business logic in XForms events, you're going to want to control some of the natural constraints, some of the things that you'd want to deal with on the client side before they do the round trip.

Then the other part of the question is versus Javascript. That part of the question is very good, because, basically you can replace your Javascript with XForms. One of the things-you can always use it as a test-if you feel like writing some Javascript into this you're probably not doing the right architecture. Because all the stuff that we have in there, by way of Javascript, should either become its forms events or it should become proper serverside Java. There shouldn't be anything left, and that's a great thing because by getting rid of Javascript you get a tremendous portability, tremendous possibility to support a variety of different browsers and channels of delivery. Javascript is terribly difficult to translate right, you basically need this Javascript processing on the client side which is not always convenient or feasible.