Convince me that JavaBeans are worth anything

In My Humble Opinion
1

I’m looking to port an application to a JSP/Java-enabled platform… I have some domain logic classes that are completely decoupled from the GUI, and I’d like to reuse these.

In JSP you can embed Java code directly into the page. If I can do that, I can instantiate and use any of my classes right in the JSP. So why on earth would I want to use JavaBeans? It just seems like a needless introduction of another abstraction language.

I’ve searched for answers, but everything I’ve read presupposes that you just use JavaBeans because duh, they’re so great, and don’t ask why.

2

I’m hardly a Java expert, having only seriously worked with it for a month now, but here’s my take:

I don’t know if this is true of all Java platforms, but on the one I’m working on at the moment, you can’t attach a debugger to code in a .JSP page. This is a serious flaw for any sort of complex code, IMO. Last week it took me a day to track down a bug that would have taken me an hour to find if I could step through the code.

Also, for code maintenance, HTML all mixed in with Java script is damn ugly. I’d much prefer to have the two files separate, for ease of reading.

3

Basically I agree with Athena for the reasons she gave. Like you, I also get sick of all the hype about whatever they’re calling the latest thing, but in this case the code is a lot easier to maintain and debug if not in the jsp.

4

I don’t have any prejudice for or against the JavaBeans or “custom tags” in and of themselves. But introducing Yet Another Macro Language on top of a perfectly adequate language (Java) seems superfluous to me. That’s why I asked.

So what I’m hearing you say is that the main benefit of JavaBeans is that it enables you to move the Java code out of the JSP. Is that about it?

5

It’s been ages since I did any Javabeans work, but my vague recollection was that they made it easier to interface between front-end (UI) code and back-end logic.

And JSPs are fun. :slight_smile:

6

Making sure we’re on the same page: JavaBeans are simply Java classes that follow a standard: Basically, they implement Serializable and their properties are exposed as getXXX, setXXX pairs. Nothing more.

They were initially conceived of to support GUI objects, like ActiveX controls, that could be plopped on a canvas and have its properties tweaked, and they fill this role quite well when using a GUI designer like JBuilder.
The more common use of JavaBeans these days is as Value Objects, carriers of data. They are particularly useful for passing business data between the various layers of an application.

Now to your question: Whether or not you are using the convoluted “use bean” syntax of the JSP, you are still working with JavaBeans in most cases.

The “use bean” tag is intended to simplify mapping HTTP POST or GET form parameters to bean properties. I don’t really like using this; in fact, I prefer using a framework such as Struts to handle getting my form properties into Java data objects and back out again.

One of the goals when working with JSPs (and hopefully ASPs) is to minimize the amount of scripting in the page. The original designers of the JSP standard were perhaps a little optimistic when they envisioned HTML developers writing the JSP while Java developers wrote tag libraries, never exposing a line of code in a JSP. Nevertheless, lots of scripting in a JSP is messy and difficult to maintain.

FYI, a JSP is nothing more than a handy way to create a servlet. All JSPs are converted into servlets in your application server, and you can even look at the servlet source code if you know where to find it.
If all JSPs become servlets, then why not cut out the middleman and write the servlet directly? Because it’s a pain in the butt. DreamWeaver can work with JSPs, but it doesn’t do servlets. Consider why we write JSPs instead of Servlets and this will give a good idea of why we want to minimize the amount of scripting buried in the JSP.

If you find yourself needing to do lots of Java in your JSP, please consider something like Struts. All form submissions go to a special servlet which calls your business interfaces and then forwards the call to a JSP of your choice which can display the result. This “model 2” architecture is much cleaner for larger applications.

7

Thank you for that very detailed response, it really helped to clear up a lot of things for me.

So if I’m understanding correctly, if I “Beanify” my business logic classes, and access them as JavaBeans or custom tags, I can get away without writing a servlet at all? (setting aside the fact that the JSP itself is technically a servlet)

8

I think that there still may be a bit of disconnect in what we are discussing.
At this point, you don’t really have to do anything at all to avoid writing servlets. You always have the option of making liberal use of <% %> and <%= %> scripting tags to embed scads of Java code in your JSP, avoiding writing a servlet altogether.

Of course, at some point you will find that you have more stuff inside the scripting tags than outside, so your JSP is looking pretty much like your servlet would have.

I tend to steer clear of writing custom tags for business logic and use standard tag libraries for rendering and logic. This is because they are slightly convoluted to write and use, so I would rather just use the ones that have already been written by someone else.

The only “Beanify” part I can see in your business logic classes would be to make them accept and return bean classes in their arguments. For example, you may have a class called “PhoneDirectory” that has a method called “findPeople” which returns a collection of “Person” bean instances, each of which is a simple data carrier with methods like “getFirstName”, “getLastName”, “getPhoneNumber” and the like. This bit would likely be buried in a bit of scripting at the beginning of your JSP.

Now, when you want to actually display the people, you could take advantage of a preexisting custom tag library of things like looping constructs in order to loop through the array of Person bean objects, and use other tags to display individual instances of Person. (though you always have the option of using <% %> scripting everywhere, tags for looping and property display are much cleaner.)

See the Standard Tag Library or Struts for good tag libraries.

Again, the main point behind the standard JSP bean usage is to provide an easy way to stuff an instance of a bean into one of the four standard JSP scopes (page, request, session, application), as well as an easy means of automatically map the URL parameters to bean properties, as shown here. I prefer to use Struts instead for this task.

9

This is getting at the point of my post, or the “disconnect” as you called it. Like you outlined above, I have business logic classes with behavior that is more sophisticated than “getProperty” or “setProperty”. Thus I was wanting to know if JavaBeans would actually buy me any simplification or reusability. If I’m hearing you correctly, the best practice is to use embedded scripting in the JSP, limited to just what is necessary to instantiate the objects as beans. My reused business logic classes can do the rest of the logical heavy lifting and I don’t have to write a servlet at all.

I guess the following question would be “why would you even use servlets” but I won’t try your generosity if you don’t have any more time for this.

10

The answer is the Model 2 architecture, preferred by most folks who do good-sized JSP projects.

From this page:

In short, servlets receive input from the users, make business calls, do all of the work; JSPs simply show stuff that was placed there by a business servlet.

Besides serving as controllers, servlets can be particularly handy for handling content that is not exactly standard HTML web page material. For example, we have a servlet that provides an interface to a report generation engine. The servlet delegates the report generation to an SQR server on a remote machine, retrieves the output via FTP, sets the returned MIME type appropriately (PDF, PostScript, Text, SQR are our options), and then returns the report output. This would not be very clean if done in a JSP.

11

I think I’ve got it now, thank you very much for the explanation. The last piece of the puzzle was understanding how much JSP’s are decoupled from the state of session objects and I think I’ve got that now.

12

Well, separation of presentation and business logic has already been covered thouroughly. Aside from making code more modular, it also gives your web developers a fighting chance of being able to redesign a page without breaking the logic. I remember having to waste my time recoding servlets because the web team decided fields in a form should be presented in a different order, and they had no idea how to make the changes themselves.

Athena: the debugger I work with can attach to a JSP. You can even put breakpoints on puely HTML statements. It’s part of the Rational Application Developer, but I think the same debugger is included in Eclipse, which is free.

13

BTW, “puely” is, in fact, an archaic form of purely. When will JelSoft implement “Quick Fixes”? :smack:

14

Eclipse is what we use, and we can’t debug .jsp pages. It really sucks.

15

Drag. I’m never sure what’s an added feature of RAD, and what comes standard with Eclipse. I guess “Debug on Server” is an addition. Well, assuming your company won’t buy you RAD, maybe you could still get them to spring for one of the Eclipse plugins that supports JSP debugging. Or, you could “keep source” and debug the generated servlet.