Sunday, February 5, 2012

Struts, an open-source MVC implementation

Posted by Unknown
Tags :
Add This To Del.icio.us Share on Facebook StumbleUpon This Add to Technorati Digg This

This article introduces Struts, a Model-View-Controller implementation that uses servlets and JavaServer Pages (JSP) technology. Struts can help you control change in your Web project and promote specialization. Even if you never implement a system with Struts, you may get some ideas for your future servlets and JSP page implementation.



A JavaServer Page (JSP) file is nothing more than another way to view a servlet. The concept of a JSP file is to allow us to see a Java servlet as an HTML page. This view eliminates all of the ugly print() statements that normally show up in Java code. The JSP file is pre-processed into a .java file, then compiled into a .class. If you are using Tomcat, you can view your pre-processed .java files in the work directory. Other containers may store the .java and .class files elsewhere; the location is container specific. Figure 1 demonstrates the JSP file-to-servlet flow.



Figure 1. JSP file-to-servlet flow
JSP to servlet flow
(This is significantly different from a Microsoft Active Server Page (ASP). An ASP is compiled into memory, not into a separate file.)
The simple self-contained JSP file
In a small JSP application, it is common to see the data, business logic, and the user interface combined into one module of code. In addition, the application generally contains the logic that controls the flow of the application. Listing 1 and Figure 2 demonstrate a simple JSP file that allows a user to join a mailing list.
<%@ page language="java" %>
<%@ page import="business.util.Validation" %>
<%@ page import="business.db.MailingList" %>
<%
String error = "";
String email = request.getParameter("email");

// do we have an email address
if( email!=null ) {

    // validate input...
    if( business.util.Validation.isValidEmail(email) ) {

        // store input...
        try {
            business.db.MailingList.AddEmail(email);
        } catch (Exception e) {
            error = "Error adding email address to system.  " + e;
        }
        if( error.length()==0 ) {
%>
            // redirect to welcome page...
            <jsp:forward page="welcome.html"/> 
<%
        }
    } else {
        // set error message and redisplay page
        error = email + " is not a valid email address, please try again.";
    }
} else {
    email = "";
}
%>
<html>
<head>
<title>Join Mailing List</title>
</head>
<body>
<font color=red><%=error%></font><br>
<h3>Enter your email to join the group</h3>
<form action="join.jsp" name="joinForm">
<input name="email" id="email" value=<%=email%>></input> 
    <input type=submit value="submit">
</form>
</body>
</html>


Figure 2. In a simple request and response, the JSP file sets the data, controls the flow to the next page, and creates the HTML
Simple request and response JSP


The mailing list JSP file is a self-contained, do-it-all module. The only things not contained in the JSP file are the actual code for validation that is contained in isValidEmail() and the code that puts the e-mail address in the database. (Separating theisValidEmail() method into reusable code might seem like an obvious thing to do, but I have seen the code forisValidEmail() embedded directly into the page.) The advantage of the single-page approach is that it is easy to understand and initially easy to build. In addition, with all the graphical development tools, it is easy to get started.





Activities of join.jsp


    

  1. Display opening input page.
    2. 

  2. Read the email value from the form parameter.
    3. 

  3. Validate the email address.
    4. 

  4. If email address is valid:
      

    • Add the address to the database.
      • 

    • Redirect to the next page.
      • 

    

    5. 

  5. If email address is invalid:
    6. 

      

    • Set an error message.
      • 

    • Redisplay join.jsp with the error message.
      • 

    







Consequences of the single-page approach


    

  • Heavy HTML and Java coupling
The coder of the JSP file must be both a page designer and a Java developer. The result is often either terrible Java code or an ugly page, or sometimes both.
    • 

  • Java and JavaScript blur
As the pages become larger, there can be a tendency to implement some JavaScript. When the JavaScript appears in a page, the script can get confused with the Java code. An example of a possible point of confusion is using client-side JavaScript to validate the email field.
    • 

  • Embedded flow logic
To understand the entire flow of the application, you have to navigate all of the pages. Imagine the spaghetti logic on a 100-page Web site.
    • 

  • Debugging difficulties
In addition to being ugly to look at, HTML tags, Java code, and JavaScript code all in one page makes it difficult to debug problems.
    • 

  • Tight coupling
Changes to business logic or data means possibly touching every page involved.
    • 

  • Aesthetics
Visually, in large pages, this type of coding looks messy. When I was doing Microsoft ASP development, I would commonly see 1000-line pages. Even with syntax coloring, it was still difficult to read and understand.
    • 




Read more on http://www.ibm.com/developerworks/library/j-struts


For Further Reading,
Programming
Pin It Now!