• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

2 complementary technology

 
ram mohan
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 5040
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the valuable piece of advice.But what is these "MVC" you all r talking about
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic