i´ve read a little about java's structure and could someone tell me if my view of all these components are correct:
JSP corresponds a View
Servlet corresponds a Controller
Bean corresponds a Model
Faces correspond layouts to render display
is this roughly correct?
JSPs are view technology - HTML with Java embedded in it.
Servlets should be used as controllers - they're Java classes that implement methods to read and write HTTP streams.
In a web app Javabeans are usually the model - JSPs and other Java view technologies understand how to access properties of Javabeans, bind them to forms, etc.
Faces is a separate stack JSF (Java Server Faces) is a component based web framework.
Yes, you're roughly correct.
Only, the Faces is more than just "layouts to render a display". JSF is a full fledged component based MVC framework which is built on top of the Servlet API. It uses the FacesServlet as the sole controller. It used to use JSP as view technology, which is now replaced by Facelets (XHTML) as per the new JSF 2.0 API. It uses the so-called backing beans as model. Then, you have taglibs/components which can be used in the view layer to generate HTML and uses Expression Language to associate the data/events with the model objects (the managed beans).
Related
Struts, Spring and a few other frameworks implement the MVC architecture to separate the representation of information from the user's interaction with it.
Can any one explain or give me a link for that in Java EE?
Without using a framework, how can I create an MVC application and what are the design patterns needed for that?
Take a look at this presentation, which is part of Beginning & Intermediate Servlet & JSP Tutorials on http://www.coreservlets.com/
you can use Servlet and Jsp to create a MVC application without using any framework,
here are some useful links,
http://forum.codecall.net/topic/72183-mvc-application-in-java/
another useful example,
http://css.dzone.com/articles/web-mvc-java
I think this is a good tutorial on Creating MVC architecture with servlets and jsp
The main concern in creating MVC architecture is the separation of concerns. You need to separate business layer, presentation layer and controler layer
Model layer is achieved by simple POJO
View layer i.e. Presentation layer can be achieved by JSP
Controllers can be achieved by servlets in java ee
MVC stands for Model View and Controller. It is a design pattern that separates the business logic, presentation logic and data.
Controller acts as an interface between View and Model. Controller intercepts all the requests.
Model represents the state of the application i.e. data.
View represents the presentaion.
This link contains an example to implement it with JSP and Servelet.
You can use Servlets and JSP directly.
For managing Java EE applications we are using design patterns.
MVC-1 and MVC-2 are design patterns for managing the UI layer.
Struts and Spring-MVC are implementations of the MVC-2 design pattern.
To answer you first question: the part of the Java EE framework that implements MVC is called JSF. This provides templates, graphical components (widgets) and much more.
To answer your second question: you don't really build an MVC app without any framework. You may be using Servlets and JSP, but that too is a framework. Java EE in its entirety is a (full stack) framework as well.
As for the third question: this is simple, the design pattern to use for MVC is MVC.
I need to get a few things cleared up. I have been looking for an answer for this one, but I can't seem to find a good answer to my specific questions (eg. this question was nibbling on the answer: Difference between servlet and web service).
To my understanding, there are different ways you can implement the "request handling", aka "Controller", in an "MVC oriented" web application, two of them being:
A Java specific Servlet (ie. one you create by clicking new ->
Servlet, in eclipse for example), used as a "Controller". This one
extends HttpServlet and you use methods like doGet and doPost etc.
A Spring MVC annotated #Controller class (yes, using a DispatcherServlet). With this one you use the #RequestMethod GET/POST etc.
Now to my questions...
When do you use one or the other?
Are there any general advantages to use one method over the other? (Like, is one method recommended over the other in general?)
[EDIT]: Emphasized keywords
If you're a student interested in learning the language then I would stick with servlets for now. It's possible to write a web app using just servlets but in practice you'll probably want to look at JSP's too.
A JSP is a convenient way to write a servlet that allows you to mix html with scripting elements (although it's recommended to avoid Java code in your jsp in favour of tags and el expressions). Under the covers it will be compiled as a servlet but it avoids you having to use lots of messy print statements.
It's important to have at least a basic understanding of servlets and JSP's. Spring MVC is one of many frameworks built on top of servlets to try make the task of writing a web application a bit easier. Basically all requests are mapped to the DispatcherServlet which acts as a front controller.
The DispatcherServlet will then call the controller whose annotations match the incoming request. This is neater than having to write these mappings yourself in the web.xml (although with servlet 3.0 you can annotate servlets now). But you also get many other benefits that can be used like mapping form fields to an object, validating that object with jsr303 annotations, map inputs and outputs to xml or json etc etc. Plus it's tightly integrated with core spring so you can easily wire in your services for the controller to call.
It's worth noting that there are a plethora of competing frameworks built on top of servlets. Spring MVC is one of the most popular so it's not a bad choice to look into.
A Servlet and a Spring MVC Controller can be used to do the same thing but they act on different level of a Java Application
The servlet is a part of the J2EE framework and every Java application server (Tomcat, Jetty, etc) is built for running servlets. Servlet are the "low level" layer in the J2EE stack. You don't need a servlet.jar to run you application because it's prepackaged with the application server
A Spring MVC controller is a library built upon the servlet to make things easier. Spring MVC offers more built-in functionalities such as form parameter to controller method parameter mapping, easier handling of binary form submissions (i.e. when your form can upload files). You need to package the required jars to your application in order to run a Spring MVC Controller
You should use a servlet when you need to go "low level", and example could be for performance reason. Spring MVC performs good but if it has some overhead, if you need to squeeze out all you can from your application server (and you have already tuned the other layers such as the db) go with a servlet. You can choose a servlet if you want to understand the foundation of the J2EE web specifications (i.e. for educational purposes)
In all the other cases you can/should choose a web framework. Spring MVC is one of them; with Spring MVC you don't need to reinvent the wheel (i.e binary form management, form parameter to bean conversion, parameter validation and so on).
Another plus of Spring MVC is that in one class you can easily manage input from different urls and methods, doing the same in a servlet is possible but the code is more complicated and less readable.
My opinion is that Spring MVC is good for building rest services and managing simple applications (i.e web application with simple forms). If you need to manager very complex forms with Ajax, nested forms, and an application with both session and page state my advice is to switch to a component based framework (like apache wicket for example).
JSF and JSP aswell as Spring MVC builts upon Servlets. The problem this that servlets are not very "nice" to work with because you have to write direct html.
If you are able to use mordern web technologies I would just use servlets in positions that need direct http output like writing an image from a database to http.
Using SpringMVC or JSF which work with a Dipatcherservlet or FacesServlet is just faster and more fun. They parse your files and send it through a servlet.
So, yeah, this is what I understood.
Servlet is just an intermediary responsible for finding out what the parameters in the request mean. These parameters are given to the .java file. It is a mere intermediary
.java file is the Model which does business logic
View is the JSP that will do the presentation
Did I get that right?
The Model View Controller pattern is not specific to Java or Servlet technology. There are many non-java MVC implementations, and in Java, there are non-Servlet implementations (Swing is an example).
In Java, when using Servlet-based MVC, usually an MVC framework is used. There are two main categories here: action based and component based, the difference being that action based frameworks listen each registered URL independently while component based frameworks keep a component tree and maintain server-side state.
Action based frameworks are Spring MVC, Struts 1+2, Stripes, Play etc. Component based frameworks are Wicket, JSF 1 & 2, Tapestry etc.
Your diagram gets close to the truth, but there are a few subtle misconceptions.
First, it doesn't make sense to speak of .java files. Java source files are totally irrelevant to a deployed web application, it uses compiled .class files only, and the JavaVM can be programmed in many different languages, so the application doesn't care whether the .class files were compiled from Java, Scala, Groovy, JRuby, Clojure, AspectJ or anything else as long as they comply to the Java Class File specification.
Second, while JSP has long been the default view technology in Java Servlet technology, it's far from the only one. Other technologies include Facelets, Velocity, Freemarker etc., and there's also nothing to stop you from writing data directly to a request from a controller without a dedicated view technology (although this is usually not advisable).
Basically, what MVC stands for is a system where there is separate code for business logic (the M), the view technology (V) and the Controller that ties things together. In a well-organized MVC architecture, the M part is so well encapsulated that the same business logic can also be executed through other channels (e.g. web services, direct library access etc.). Also, it should be possible to switch view technologies through configuration from the outside without editing the actual controller logic.
I would advise you to read the docs for the Spring MVC framework, it is to my knowledge the most robust (and also easy-to-use) MVC framework out there, and the tooling support is also great (in either InteliJ Idea or the Eclipse-based SpringSource Tool Suite).
When you are talking about MVC, then all three layers should be separated from each other.
In web application :
1: A controller should be responsible handling the user request then filtering & executing the appropriate actions and then forward the generated response to the client.
2: A model consist of your Business logic,beans & Pojo classes. This should deal with you logic ,perform some operation and renders the generated result to some kind of persistent object or DTO's.
3: A view is consist of your GUI, some presentation-logic , it should be separated from your back-end ,ultimately you are showing an encapsulated form of result to your client i.e. what a client actually needed.
There are two types of MVC: MVC1(Push-MVC) and MVC2(Pull-MVC)
Pull-MVC and Push-MVC are better understood with how the view layer is getting data i.e. Model to render. In case of Push-MVC the data( Model) is constructed and given to the view layer by the Controllers by putting it in the scoped variables like request or session. Typical example is Spring MVC and Struts1. Pull-MVC on the other hand puts the model data typically constructed in Controllers are kept in a common place i.e. in actions, which then gets rendered by view layer. Struts2 is a Pull-MVC based architecture, in which all data is stored in Value Stack and retrieved by view layer for rendering.
So I understand that JSPs are a mixture of a client-side code (DHTML, JS, CSS, etc.) and Java. In this way, JSPs are kind of like pure PHP or pure ASP. When the web container receives a request for a JSP, it compiles the Java inside the JSP, executes it and then returns the resultant client-side code in the HTTP Response.
I also understand that an alternative to JSPs are Servlets, or a Servlet/templating combo, like FreeMarker. The servlets contain pure Java (business logic), and the templates contain presentation logic.
What I don't understand is how JSF-derived technologies like RichFaces, PrimeFaces and ICEFaces turn Java code into client-side code that can run in a browser. I've also heard that the major draw to these frameworks are the "rich" UI controls they come with, but am having a tough time connecting all the dots.
Do these frameworks get compiled to JS like the GWT does? If that's the case then I would assume that these rich UI controls would be the same as, say, jQuery UI controls that are just pure JS.
If that's not the case then I just don't understand (at all) how these frameworks turn server-side code into "stuff" that can execute client-side.
Thanks in advance!
What I don't understand is how JSF-derived technologies like RichFaces, PrimeFaces and ICEFaces turn Java code into client-side code that can run in a browser
The HTML is generated by encodeXxx() methods of UIComponent and/or Renderer implementations. Those methods are invoked during render response phase, starting with the UIViewRoot which delegates the call all the way through the entire component tree hierarchy.
JSF implementations such as Mojarra and practically all component libraries are open source. To take the JSF standard <h:inputText> component as an example, start looking at com.sun.faces.renderkit.html_basic.TextRenderer class to see all the HTML generating code.
Do these frameworks get compiled to JS like the GWT does?
Absolutely not. Open a JSF page in browser, rightclick and View Source. It's all just HTML code, if necessary along with auto-included CSS/JS files. With GWT it's one and all JS code.
See also:
Java EE 6 tutorial - Creating custom components - to learn how to program it yourself.
What is the difference between JSF, Servlet and JSP?
What is the need of JSF, when UI can be achieved from CSS, HTML, JavaScript, jQuery?
No, JSF is not something like GWT. The idea is different. But let's start from the beginning.
Servlets are not really alternative to JSP. JSP is a technology, which is responsible for View part in Model-View-Controller design pattern. Servlets usually play role of the Controller.
In a typical scenario Servlet receives request from the user, parses it and calls bussines logic (Model) - it could be just the set of java classes or EJB components or whatever else which calculates something, talks to database, etc. Then Servlet gets the data from bussines logic (if any) and redirects user to a proper View element - JSP, pure HTML page, some template engine, etc.
JSF is sort of a layer over JSP + Servlets that makes programmers' live easier (although many would strongly diagree with that :) )
JSF page is basically a JSP page, that uses set of specialized tags - components (JSF native tags or RichFaces tags or ICE Faces tags). These tags can be written in Java, can boundle JavaScript, CSS. The final effect is that these tags generate HTML representing "component", for instance fancy table with sorting capabilites.
So you have for instance component that you place on JSP page and it represents nicely looking table.
In addition JSF is armed with standard controller, which is not written in Java, but is a set of navigation rules between pages written in XML.
One more element are JSF Beans, which are bounded to JSF pages and are automatically filled with data taken from these pages. It is often quite straighforward - user fills the form, which is a part of JSF page (form also use specialized tags - components). Once this form is submitted the JSF Bean class is filled with data and action method is called. The action method returns a string, which is used to identify page to which user should be redirected (the rule is taken from XML controller configuration).
So in case JSF the frontend part is generated in backend - JSF tags (or components, as people call them) are interpreted in the backend and the backend generates HTML from them.
This could be contrasted with thechnologies, which separates frontend and backend. Backend receives and returns data in the form of XML or, more often, JSON and exchanges them with frontend part of the application. Frontend could be written in JavaScript, Flex, etc. So backend and frontend are totally separated.
I am using MVC design pattern in jsp-servlet web application, and want to what is the exact difference between MVC1 and MVC2 , can someone help?
EDIT newly I hear that there is 2 versions of using MVC in servlet programming, I hear that in MVC1 there is kind of coupling between controller and view , but in MVC2 they overtake it, if someone know whether this is right or wrong I'll be very thankful.
It might be possible that you read this version in connection with asp.net MVC, as there different versions of that framework. There is no version 2.0 of the mvc pattern, just a version 2.0 of the asp.net MVC framework.
In context of jsp servlets see: Model 1 and Model 2. In a nutshell: Model 1 doesn't have a controller to dispatch requests, Model 2 does.
In MVC 1, controller and model,both are JSP. While in MVC2 controller is servlet and model is java class.
In MVC1 there is tight coupling between page and model as data access is usually done using Custom tag or through java bean call.
In MVC2 architecture there is only one controller which receives all the request for the application and is responsible for taking appropriate action in response to each request.
MVC1 was a first generation approach that used JSP pages and the JavaBeans component architecture to implement the MVC architecture for the Web. HTTP requests are sent to a JSP page that implements Controller logic and calls out to the Model for data to update the View. This approach combines Controller and View functionality within a JSP page and therefore breaks the MVC paradigm. MVC1 is appropriate for simple development and prototyping. It is not, however, recommended for serious development.
MVC2 is a term invented by Sun to describe an MVC architecture for Web-based applications in which HTTP requests are passed from the client to a Controller servlet which updates the Model and then invokes the appropriate View renderer-for example, JSP technology, which in turn renders the View from the updated Model.
The hallmark of the MVC2 approach is the separation of Controller code from
content. (Implementations of presentation frameworks such as Struts, adhere to the MVC2 approach).
That's what I found here: http://www.theserverside.com/discussions/thread.tss?thread_id=20685
MVC-1 Architecture
1) In MVC-1 Architecture, single web component(Servlet/JSP) is used as Controller and view but for other layers separate web components are taken....
2) Since, single component is taken as Controller and view, logics are mixed up..
MVC-2 Architecture
1) In MVC-2 Architecture separate components should be taken for separate layers...
2) Logics are not mixed, there is clean separation between the logics....