JSP or Servlets?

I am very much a newbie in the java world, so can anyone please explain to me what advantages Java servlets have over Java Server Pages?

As far as I have read, JSP compiles to a servlet class and is invoked exactly like a servlet after it has been compiled for the first time.

Compared to JSP, I find servlets a bit tricky to deploy, sp is there any reason to use a servlet in any case?

Servlets are not nearly as easy to write when you are starting out. The basic rule of thumb is: If you have a lot of logic (alot of code) that needs to be written and little html, use a servlet. If you have a lot of html, use a JSP.

I cant tell u advantages really but i can say when i feel it is useful.

well i personally like servlets when there is alot to be coded. I like to keep my JSP with small fragments of code. Leave the heavy coding to Servlets

a time i always use it when it comes to using objects and stuff seems soo much easier to me then using JSP.

I usually also handle all form processing through servlets. Since form processing is all code might as well just use a servlet.

Also if you ever want to create images on the fly servlets seem to be easier.

There is alot more just few reasons to seperate em.

Nemi <- I keep HTML in templates and use a template processor to produce output. So I guess you would say that a servlet is the best choice?

Shocka <- Is it not possible to declare classes inline in JSP like it is in a normal Java file?

Nemi <- I keep HTML in templates and use a template processor to produce output. So I guess you would say that a servlet is the best choice?

Shocka <- Is it not possible to declare classes inline in JSP like it is in a normal Java file?

Hrm, if you are merely including template files (i.e., <%@ page include="someFile.html" %>) then I would say either would work. To be honest, the only thing that is really frowned upon is putting lots of scriptlets (java code between <% %> tags) in jsp's and lots of html in servlets. If implementing yours either way would not amount to either of these conditions, the choice is basically yours. Did I explain that well?

Well you can create objects, but i would be one to say this is an horrible coding style even though sometimes its usefull and efficient, i still believe it is a bad codign style

One the other hand using Java Beans in JSP is really simple and nice and that is all based on XML specifications. Usually this is the only time i declare objects inside a JSP.

I personally see myself normally running away from OO programming when i stick to JSPs, which is also a reason i use servlets

I think this conversation is going to get indepth and confusing quick....

def a good question, i like to see what others think when programming, sometimes they reveal things u would never even think about.

From what you both write, I can conclude that:

JSP when minimal program code is enough.
Servlet when a lot of processing is done.

Furthermore: with JSP, use beans for commonly used code(?)


I hope that I did not misunderstand any of you, if I did, please correct me

I generally tend to use JSPs only as the "view" part of the model-view-controller architecture.

for the model part I use JavaBeans that implement a persistance interface and a Factory class to manage them.

for the controller part I use Struts ActionServlets to delegate requests to the Factory/Manager class (that in turn tells the JavaBeans what to do with themselves).

for the view I use Struts tags, and custom taglibs without ANY logic code on the page. in fact with the exception of a few <%=request.getParameter("foo")%> tags my pages look pretty much like plain HTML/XML

so basically Beans for dealing with data.
servlets for dealing with logic.
JSPs for presenting the data and accessing the logic.

You pretty much got it.

StinkFist <- That sounds VERY interesting, though a bit too advanced for a n00b like me. There is, however, one thing, I need explained: If your servlet handles the request, how do you invoke your JSP to create the response?

Is you Factory class a Java bean as well? If not, how do you access it from within JSP?

StinkFist <- Oh, I think I get it - Struts have some way of invoking JSP from a servlet, right?

By the way: If I use a template processor within a servlet, and use template manipulation instead of invoking a JSP page, would that still be considered to be part of the view layer or would it be a part of the controller?

Forgive me my ignorance, but I am totally unfamiliar with design patterns, and, as I said before, Java web technologies.

I'm a little under the weather right now so I will go ahead and preface this by saying that I'm probably full of sh*t (I'll edit this in the morning... )

think about your JavaBeans as an extension of your database. they are the data objects that you want to be able to keep track of. things like users, shopping carts, widgets, etc... In order to make these items persistant across server restarts and user visits you have to store them in some way (ie the database).

in order to make them real self-aware objects they need to be able to take care of thier life-cycle needs. things like Creating new instances, Retrieving stored instances Updating themselves and finally Deleting themselves if necessary (this is called the CRUD design pattern, although I think the objects themselves should own responsibility for thier actions and not thier manager).

then think about a central object that is responsible for controlling all of these persistant objects. This object must be aware of the persistant object's interfact but doesn't require any other knowledge. all its job entails is passing messages to the persistant objects and letting them do what they will with those messages.

fair enough. that's the model layer.


now let's skip up to the view.

a user is shopping for a widget (which is one of our model objects that implement the persistable interface). the user sees a list of widgets provided by a set of custom taglibs that access the data of our JavaBean model objects. the only thing the tags are doing is querying the "get" methods of our objects.

the data is formatted in the page by a designer who doesn't know or care (or have to know or care) about the underlying model. all she knows about is that she has the data she needs.

now a visitor decides he wants to buy one of these widgets. he clicks a link that links to a Struts ActionServlet...

here's our Controller.

the controller is a servlet and recieves a request object that it can examine to determine what particular widget was chosen. from there it can tell the widget what to do with itself via the Factory class we talked about first.

ie a widget is clicked on in the view, a controller servlet gets the information and asks the model object manager to tell a ShoppingCart bean to add a Widget bean to its WidgetBeans container. This proceeds until check-out.

at each point the servlet is relaying data back to the view, telling it whether to present things like error messages or confirmation notices.

I might be a little obscure right now (its St. Paddy's day weekend so I've had a couple of whiskeys...) I swear I'll clarify in the morning tho

Oh, that helped a lot actually

The only thing, I'm still confused about is this factory class. Is it something that creates an instance of a class and returns an interface, like in COM? What is it's role in terms of the MVC pattern?

The Factory is a design pattern. basically what it means is that you want one and only one place responsible for creating new objects. Typically when you create a new object you call its constructor



this is fine and dandy but for some objects (in this case our Persistable objects) we want more control over how they come into the world and how they leave. If we make one class responsible for creating new instances of objects it allows for more flexibility and control. the Factory method is static

It's desirable to only have one instance of a factory object available to the application so we implement the Singleton design pattern. we make the constructor private and all of the methods static.

a big bonus (especially in the case of a web database application) is that we can do things like cache objects in the factory and reuse them instead of querying the database every time. This is called "Lazy Instantiation".

this is obviously VERY simplified, you would have several methods that managed the cache, added and deleted objects from the cache.

In my current project the factory method of my factory class takes a fully qualified class name as the argument and after validating that the class implements the proper interface it is retrieved from the cache or instantiated. The method is overloaded to take an object id as well in the case of instantiating a particular object (like a user with a userId).

I hope that helps
cheers