Window 2 World

MVC
---
Many clever developers realized that JavaServer Pages AND servlets could be used together to deploy web applications. The servlets could help with the control-flow, and the JSPs could focus on the nasty business of writing HTML. In due course,using JSPs and servlets together became known as Model 2 (meaning, presumably, that using JSPs alone was Model 1).

Of course, there is nothing new under the Sun ... and many have been quick to point out that JSP's Model 2 follows the classic Model-View-Controller design pattern

In the original SmallTalk Model-View-Controller framework, an application is seen as having three distinct parts. The problem domain is represented by the Model. The output to the user is represented by the View. And, the input from the user is represented by Controller.

In Smalltalk MVC, the View updates itself from the Model, via the "Observer" pattern. The original MVC pattern is like a closed loop: The View talks to the Controller, which talks to the Model, which talks to the View.But, a direct link between the Model and the View is not practical for web applications, so we modify the classic MVC arrangement so that it would look less like a loop and more like a horseshoe with the controller in the middle.

The Model: System State and Business Logic JavaBeans
The View: JSP Pages and Presentation Components
The Controller: ActionServlet and ActionMapping

Scope
-----
page - Beans that are visible within a single JSP page, for the lifetime of the current request. (Local variables of the service method)

request - Beans that are visible within a single JSP page, as well as to any page or servlet that is included in this page, or forwarded to by this page. (Request attributes)

session - Beans that are visible to all JSP pages and servlets that participate in a particular user session, across one or more requests. (Session attributes)

application - Beans that are visible to all JSP pages and servlets that are part of a web application. (Servlet context attributes)

ActionForm
-----------
If you declare such beans in your Struts configuration file , the Struts controller servlet will automatically perform the following services for you, before invoking the appropriate Action method: Check for an instance of a bean of the appropriate class, under the appropriate key, in the appropriate scope (request or session).
If there is no such bean instance available, a new one is automatically created and added to the appropriate scope (request or session).
For every request parameter whose name corresponds to the name of a property in the bean, the corresponding setter method will be called. This operates in a manner similar to the standard JSP action when you use the asterisk wildcard to select all properties. The updated ActionForm bean will be passed to the execute method of an Action class [ org.apache.struts.Action ], so that the values can be made available to your system state and business logic beans.

The validate method is called by the controller servlet after the bean properties have been populated, but before the corresponding action class's execute method is invoked.

controller
----------

For those of you familiar with MVC architecture, the ActionServlet represents the C -the controller. The job of the controller is to: process user requests,
determine what the user is trying to achieve according to the request,
pull data from the model (if necessary) to be given to the appropriate view, and
select the proper view to respond to the user.

Think of your ActionForm beans as a firewall between HTTP and the Action. Use the validate method to ensure all required properties are present, and that they contain reasonable values. An ActionForm that fails validation will not even be presented to the Action for handling.

DynaActionForms are not a drop-in replacement for ActionForms. If you need to access DynaActionForm properties in your Action, you will need to use the map-style accessor, like myForm.get("name"). If you actively use the ActionForm object in your Action, then you may want to use conventional ActionForms instead.

The required knowledge has been encapsulated in a Java class named ActionMapping , the most important properties are as follows:

type - Fully qualified Java class name of the Action implementation class used by this mapping.
name - The name of the form bean defined in the config file that this action will use.
path - The request URI path that is matched to select this mapping. See below for examples of how matching works and how to use wildcards to match multiple request URIs.
unknown - Set to true if this action should be configured as the default for this application, to handle all requests not handled by another action. Only one action can be defined as a default within a single application.
validate - Set to true if the validate method of the action associated with this mapping should be called.
forward - The request URI path to which control is passed when this mapping is invoked. This is an alternative to declaring a type property.

Internationalization
--------------------
for making struts to work with specific locale we can change the value for the key "Action.LOCALE_KEY" (which is stored in the session) or we have to change the locale settings in the browser and then hit the corresponding site.

errors in the request
----------------------
The framework stores the errors in the request, and so when you redirect, they disappear. The usual work around is to save the ActionErrors to the session yourself, and then move them from the session back to the request in the Action to which you are redirecting. If you do a lot of this, the routine could be made part of a base Action, a servlet subclass, or RequestProcessor in Struts 1.1.

Note : extracted from Apache site.

# posted by srikanth : 11:23 PM  0 Comments

Following is the description about JUnit

Test suite
A TestSuite is a Composite of Tests. It runs a collection of test cases. Here is an example using the dynamic test definition.

TestSuite suite= new TestSuite();
suite.addTest(new MathTest("testAdd"));
suite.addTest(new MathTest("testDivideByZero"));

Alternatively, a TestSuite can extract the tests to be run automatically. To do so you pass the class of your TestCase class to the TestSuite constructor.

TestSuite suite= new TestSuite(MathTest.class);

This constructor creates a suite with all the methods starting with "test" that take no arguments.

Test Case
A test case defines the fixture to run multiple tests. To define a test case

1) implement a subclass of TestCase

2) define instance variables that store the state of the fixture

3) initialize the fixture state by overriding setUp

4) clean-up after a test by overriding tearDown.

5) For each test implement a method (starting with "test") which interacts with the fixture.Verify the expected results with assertions.(example assert methdos overloaded asserEquals,assertNotSame,assertTrue,assertNull)

AssertionFailedError is thrown when an assertion failed.

Running Test Cases
we can run the test cases in the following three ways

1)Once the methods are defined you can run them. The framework supports both a static type safe and more dynamic way to run a test. In the static way you override the runTest method and define the method to be invoked. A convenient way to do so is
with an anonymous inner class.

TestCase test= new MathTest("add") {
public void runTest() {
testAdd();
}
};
test.run();

2)The dynamic way uses reflection to implement runTest. It dynamically finds and invokes a method. In this case the name of the test case has to correspond to the test method to be run.

TestCase test = new MathTest("testAdd");
test.run();

3)The tests to be run can be collected into a TestSuite. JUnit provides different test runners which can run a test suite and collect the results. A test runner either expects a static method suite as the entry point to get a test to run or it will extract the suite automatically.

public static Test suite() {
suite.addTest(new MathTest("testAdd"));
suite.addTest(new MathTest("testDivideByZero"));
return suite;
}

small example
package testapp;
public class Example {
public boolean testOne(String str){
if(str.equalsIgnoreCase("yes")){
return true;
}else{
return false;
}
}
public boolean testTwo(int i,int j){
if(i>j){
return true;
}else{
return false;
}
}
}

package testapp;

import junit.framework.*;

public class ExampleTest extends TestCase {

Example instance;

public ExampleTest(String testName) {
super(testName);
}
protected void setUp() throws Exception {
instance = new Example();
}
protected void tearDown() throws Exception {
instance = null;
}
public static Test suite() {
//TestSuite suite = new TestSuite(ExampleTest.class);
// eihter use the above line or the following three lines
TestSuite suite = new TestSuite();
suite.addTest(new ExampleTest("testOne"));
suite.addTest(new ExampleTest("testTwo"));
return suite;
}
public void testOne() {
String str = "";
boolean expResult = true;
boolean result = instance.testOne(str);
assertEquals(expResult, result);
}
public void testTwo() {
int i = 0;
int j = 0;
boolean expResult = true;
boolean result = instance.testTwo(i, j);
assertEquals(expResult, result);
}
}