2 complementary technology

[ram mohan]

Hi folks,
we have 2 complementary technology to a great extend ;Servlets and JSP.
So is there any rule of thumb saying Servlets suits for this kind of requirements and JSP suits for this kind of requirements?
Because this is very useful in deciding the project technology at the initial stage
Look forward an interesting dicussion from java gurus who have done many projects using these technologies
Rgds
ram

[Madhav Lakkapragada]

Well there is and the classical answer is it depends.
When applications follow a Model View Controller (MVC) pattern,
Servlets (among others) take the role of Controller and JSP's
(among others) take the role of View.
regds.
- satya

[Peter den Haan]

Briefly, if your page is mainly concerned with presentation, use a JSP. If it is more concerned with processing, use a servlet. Should it be doing both in equal measure, some refactoring is in order -- delegate the processing to servlets, beans, or tag libraries.
If you go for the MVC (Model 2) pattern, the View wants to be a jsp because it's 100% presentation; any processing concerned with presentation and accessing the model could go into taglibs. The Controller wants to be a servlet, since there is no presentation component to it. The Model, finally, really wants to be an EJB, JavaBean, Java class, or a mix of the three.
- Peter

[ram mohan]

Thanks for the valuable piece of advice.But what is these "MVC" you all r talking about

[Frank Carver]

The term is expanded in the post from Madhav Lakkapragada above. MVC stands for "Model View Controller". It is a pattern comprised of three components:
+ A Model which holds the data. Data changes only affect the model.
+ A View which shows some information about the data.
+ A Controller which looks after updating the data in the model, and makes sure the View retrieves the updated data if it changes.
As an example, consider a simple calculator application. The View consists of the display and the available buttons. The view knows nothing about how teh calculator works, or what numbers are stored in it. It just knows how to send "button-clicks" to the Controller, and how to get the digits to display from the Model.
When a button is clicked, the View tells the Controller which gathers the digits until an operation is clicked, at which point it sends the constructed number to the model, together with the operation. The model processes the operation, and updates its displayable results if appropriate. The View may then be updated to show the result.
This may seem overcomplicated for such a small application, but it has real benefits. Separating the View from the Model allows many different views, skins, look-and-feels or whatever to exist without changing the logic. Separating the Controller from the Model allows the Model to be coded in terms of domain operations (in this case, imagine a method call like perform("123456", SQRT), rather than the model having to deal with gluing the digits together into a number)
Has this helped?