How to re-use existing classes in JSP/JavaBeans/Servlets

[thecrow]

OK, this is somewhat of a neophyte question but I don't know where else
to ask it.

What is the best way to integrate existing Java classes into a web
page? These are purely domain logic classes... no presentation or
anything. I looked into JavaBeans, but this technique seems to have
some serious problems... it seems that JavaBeans cannot be anything
except data objects, as they must conform to a rigid getter/setter
paradigm.

Servlets seem like the way to go, but it seems I lose the ability to
mix HTML with the code.

How do I do this with Java? It doesn't seem to have any easily
accessible way to reuse classes in web pages, at least as far as I can
tell.

 

[Wendy S]

What is the best way to integrate existing Java classes into a web
page? These are purely domain logic classes... no presentation or
anything. I looked into JavaBeans, but this technique seems to have
some serious problems... it seems that JavaBeans cannot be anything
except data objects, as they must conform to a rigid getter/setter
paradigm.

Servlets seem like the way to go, but it seems I lose the ability to
mix HTML with the code.

You can use both Servlets and JSP. Do the processing including calling
those Java classes in the Servlet, place objects (these might be 'beans')
into the request (or session), then forward to a JSP to display the results
of the processing.

You might want to take advantage of an existing 'framework' such as Spring
or Struts.

 

[thecrow]

But is the servlet itself not also a "bean?" I guess I don't get how
to call servlets from JSP. If I can instantiate a servlet from JSP,
then why can't I just call my classes natively from JSP?

 

[Wibble]

JSP's are servlets. They're just code generated from HTML plus
some special tags. Buy a book.

 

[Malte]

OK, this is somewhat of a neophyte question but I don't know where else
to ask it.

What is the best way to integrate existing Java classes into a web
page? These are purely domain logic classes... no presentation or
anything. I looked into JavaBeans, but this technique seems to have
some serious problems... it seems that JavaBeans cannot be anything
except data objects, as they must conform to a rigid getter/setter
paradigm.

Servlets seem like the way to go, but it seems I lose the ability to
mix HTML with the code.

How do I do this with Java? It doesn't seem to have any easily
accessible way to reuse classes in web pages, at least as far as I can
tell.

Be pragmatic and just use the classes from within the JSP.

 

[Wendy S]

But is the servlet itself not also a "bean?" I guess I don't get how
to call servlets from JSP. If I can instantiate a servlet from JSP,
then why can't I just call my classes natively from JSP?

Keep in mind that I subscribe to a particular world view in which processing
is done in Servlets and JSPs are strictly used to display things, with very
little logic. So the request comes directly into a Servlet, it looks at the
request parameters, instantiates objects and calls methods on them, stores
some information in the request/session, then forwards to a JSP.

You don't instantiate Servlets, the Servlet container does that. Neither do
you 'call' Servlets from JSP.

A "bean" can be nothing more than a plain old Java class that follows some
naming conventions. [IMO, the marketing department at Sun got a bit out of
hand with the whole JavaBeans(tm) thing.] So no, the Servlet isn't a bean.
As you noted, they're mostly data objects, with get/set methods to expose
the properties.

You *can* call your classes natively from the JSP. (*I* wouldn't, but
nothing's stopping you.) A JSP gets converted to Servlet code behind the
scenes, so you can put anything you want in it. Just enclose the Java code
in <% %> (I think...) and it will get picked up and compiled.

Can you describe the problem you're trying to solve? Talking about actual
code rather than generalities might be helpful at this point.

 

[thecrow]

The problem I am trying to solve is fairly simple... I have classes
that encapsulate domain logic and have no presentation. I want to use
them in a web app by creating a JSP/servlet presentation for these
classes. My question is, using best practices in an architecturally
sound design, where and how would I instantiate and call these classes?
I do not like the look of JavaBeans but I also do not want to call a
thousand print statements from a servlet.

As a basic analogy for what I'm doing, consider a pre-existing
TarotDeck class which contains a collection of TarotCard objects along
with a DeckIterator. I want to instantiate them and have the instance
accessible to other servlets/jsp's called from the same session... do
not want to re-instantiate them every page. The presentation will
have buttons to navigate forward and backward within the deck. There
will be more than one page involved... perhaps another page will have
the ability to edit the stack and add or remove cards.

I've read docs on the subject but there are a lot of ways of doing
it... I just need to hash it out in an actual conversation with someone
with some experience in the area.

 

[Juha Laiho]

The problem I am trying to solve is fairly simple... I have classes
that encapsulate domain logic and have no presentation. I want to use
them in a web app by creating a JSP/servlet presentation for these
classes. My question is, using best practices in an architecturally
sound design, where and how would I instantiate and call these classes?
I do not like the look of JavaBeans but I also do not want to call a
thousand print statements from a servlet.

As a basic analogy for what I'm doing, consider a pre-existing
TarotDeck class which contains a collection of TarotCard objects along
with a DeckIterator. I want to instantiate them and have the instance
accessible to other servlets/jsp's called from the same session...

Ok, so the lifecycle is that of the client session. One more data point.

do not want to re-instantiate them every page. The presentation will
have buttons to navigate forward and backward within the deck. There
will be more than one page involved... perhaps another page will have
the ability to edit the stack and add or remove cards.

Then, when a session starts, you create an instance of your processing
logic. That you store as a session attribute (which will be available
to all servlets and JSPs called during the same session).

Process all data that comes in a HTTP request within a servlet -- they're
well suited for that. Then, when the data is converted into something
you can feed to your processing logic, just let your processing logic
handle the data. Note that beans can be just interface-deep, so the
data can come from other classes -- f.ex. from your domain logic. Beans
are a good match with JSPs, and JSPs are good for creating HTML views.

So, when your servlet has handed the to-be-processed data into your
domain logic, you forward the request (internal forward within the
servlet engine) to a JSP, which provides the new data view, calling
bean-like objects to provide the actual data. Or, implement a set of
custom tags (building a tag library) to handle the presentation of
your data within the JSP document.

 

[thecrow]

Thanks for that previous reply... I just have one more question: in
the architecture you've described above, where is the responsibility
for presenting forms? Would the form be presented in a JSP with a
submit action that goes to the servlet?

 

[Wibble]

Dude, your getting sloppy advice. Buy a book, really.
Theres alot of ways to do this wrong. You dont have a
good understanding of beans, custom tags or JSP's and servlets.
Read up on it.

 

[christopher]

The issue here is your use of terms "like" and "want" juxtaposed with
"best practices". Why ask someone else's opinion when you are strongly
opinionated and poorly informed?

I write HTML documents with my own tags in them using square brackets,
and filter these through a servlet. Crude, but I have a body of
methods already written and I can develop in HTML and hack in my tags
where the interactive data goes.

I strongly echo "buy a book", and recommend van der Linden

 

[thecrow]

The issue here is your use of terms "like" and "want" juxtaposed with
"best practices". Why ask someone else's opinion when you are strongly
opinionated and poorly informed?

Perhaps I acknowledge my own limitations and seek the input of others?

I write HTML documents with my own tags in them using square brackets,
and filter these through a servlet. Crude, but I have a body of
methods already written and I can develop in HTML and hack in my tags
where the interactive data goes.

So you've introduced your own macro language, so to speak?

I strongly echo "buy a book", and recommend van der Linden

At the moment I am not in a place where I can readily get
English-language books, otherwise I would do so. Is this not the
internet age? Are there no suitable web sites?

 

[Wendy S]

At the moment I am not in a place where I can readily get
English-language books, otherwise I would do so. Is this not the
internet age? Are there no suitable web sites?

Lots, but authors need to eat, too. If you can't get to "real" books,
there's http://safari.oreilly.com/ where you can 'subscribe' to books and
read them online. Given how fast tech books go out of date, this is a great
service.

Also, the J2EE tutorial from Sun:
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/
Pick and choose, you don't need all of it, but chapters 11 and 12 should
sort out Servlets and JSP for you.

You might want to read the JavaBeans Specification also, I don't quite
understand why you dislike them so much, and they're VERY useful. For the
most part, it's just a set of naming conventions.
http://java.sun.com/products/javabeans/docs/spec.html

 

[Juha Laiho]

Thanks for that previous reply... I just have one more question: in
the architecture you've described above, where is the responsibility
for presenting forms? Would the form be presented in a JSP with a
submit action that goes to the servlet?

Yep; all HTML in your JSP. JSP is the place to manage how data is
presented to the user.

 

[Wibble]

Theres alot of good template engines out there. I used freemarker and
liked it. They are all easier to use than JSP's and probably will do
what you want.

 

[thecrow]

You might want to read the JavaBeans Specification also, I don't quite
understand why you dislike them so much, and they're VERY useful.

OK, help me with this. My dislike is just a knee-jerk first response
against the fact that they seem to be data-only objects, restricted to
getters and setters, devoid of any logic whatsoever. I don't "get" why
using a traditional JavaBean would ever be preferable to just accessing
the object directly. It seems like an extra layer added with no
benefit. Maybe it's good for delegating interface development to
people who don't know Java?

Thanks for the safari reference BTW... I subscribed to it and I'm
beginning to read up on the subject. I understand the "what" a lot
better now, but I am just not getting the "why", specifically about
using JavaBeans in a web app.

 

[thecrow]

You might want to read the JavaBeans Specification also, I don't quite
understand why you dislike them so much, and they're VERY useful.

OK, help me with this. My dislike is just a knee-jerk first response
against the fact that they seem to be data-only objects, restricted to
getters and setters, devoid of any logic whatsoever. I don't "get" why
using a traditional JavaBean would ever be preferable to just accessing
the object directly. It seems like an extra layer added with no
benefit. Maybe it's good for delegating interface development to
people who don't know Java?

Thanks for the safari reference BTW... I subscribed to it and I'm
beginning to read up on the subject. I understand the "what" a lot
better now, but I am just not getting the "why", specifically about
using JavaBeans in a web app.

 

[Wibble]

Beans are nice because its easy to set breakpoints, or insert
print statements, reflective tools like them, and the compiler
will optimize away the getters and setters. Beans used by
JSP's are a place to hide your biz logic. If you werent also
adverse to reading, you might find this out.

 

[Wendy S]

OK, help me with this. My dislike is just a knee-jerk first response
against the fact that they seem to be data-only objects, restricted to
getters and setters, devoid of any logic whatsoever.

Then your dislike is totally unfounded, because JavaBeans are not restricted
to getters and setters, nor must they be devoid of logic.

I don't "get" why using a traditional JavaBean would ever be preferable to
just accessing
the object directly. It seems like an extra layer added with no benefit.

Okay, I'll play. Give an example of an object you'd rather just access
directly, in order to display information on a JSP. No scriptlets allowed,
only JSTL 1.0.

 

[thecrow]

benefit.

Okay, I'll play. Give an example of an object you'd rather just access
directly, in order to display information on a JSP. No scriptlets allowed,
only JSTL 1.0.

Well, of course "no scriptlets allowed" means "JavaBeans required".
It's no surprise that an artificial restriction requires an artificial
solution. Why did you introduce that restriction, do you encounter
many cases where there is a real restriction against using scriptlets?