Professional Documents
Culture Documents
Struts 2.0
Session - 2
May, 2009
Presentation By
Training & Development
Introduction
On Day 1, we discussed the
Welcome Back! following:
Lets start with a – Introduction to Software
small recap of Day 1 Framework
– Struts Background
Day 2
– Today we will be discussing
about things that you should
know before you start learning
Struts 2
2
Mr. Thinker
3
Mr. Thinker
4
Mr. Thinker
5
Dumbo Vs. Jumbo
Jumbo! Does JSPs completely replace Servlets?
6
Mr. Thinker
7
Mr. Thinker
8
Mr. Thinker
View Layer is generally
What is the View layer implemented using JSPs
generally made of?
9
Dumbo Vs. Jumbo
What puzzle does MVC solve?
10
Dumbo Vs. Jumbo
Jumbo! Tell something about Struts?
11
Things you should know before you learn Struts 2
12
Filters
Before we jump into Struts 2.0 sessions we will be undertaking a crash
course on few of the concepts that all of us should be aware of.
Filters belong to Servlet specification
13
Filters
My name is Session filter. Like authentication
filter, I also grab each request object before it
reaches the servlet. My responsibility is to check
whether the session is still alive. Only if alive, I
allow the request to proceed further with the
business process. Coming back to this request, yes
the session is valid, over to the servlet
HTML Client
Hi Server, Post
these customer
details to the
database
Filters
15
Dependency Injection
• Dependency Injection refers to the process of supplying an external
dependency to a software component
Traditional Love
16
Dependency Injection
Dependency Injection Love
17
Technically Speaking
Traditional Love Class
public class Romeo
{
18
Dependency Injection
//Juliat prays to Love God using this interface. He expresses his desire through this interface
public interface LovePrayer {
public void setMyLove(MyLove loverObject);
}
//Juliat prays to Love God by implementing LovePrayer.
//Love God promptly responds by setting Juliat into Romeo’s “MyLove”
public class Romeo implements LovePrayer {
this.juliat = juliat;
}
public void spendRestOfMyLife( ) {
//God has given me what I want. Now my life will be sweet
juliat.spendLifeTogether( );
}
}
19
Dependency Injection in a Nutshell
Conventionally, if an object A needs to gain access to a particular object B,
object A takes responsibility to access Object B: either it holds a direct
reference to B, or it goes to a known service locator and requests for a
reference to B
By contrast, using dependency injection, Object A simply provides a
property that can hold a reference to Object B; then, when the object A is
created, a reference to Object B will automatically be injected into that
property by an external mechanism.
20
Annotations
Annotations are syntactic form of metadata
21
Annotations - Example
@Stateless
public class CalculatorBean implements Calculator {
public double calculate (int start, int end,
double growthrate, double saving) {
double tmp = Math.pow(1. + growthrate / 12.,
12. * (end - start) + 1);
return saving * 12. * (tmp - 1) / growthrate;
}
}
22
Annotations
In the above example, the annotation states that the EJB is a stateless
Session Bean
That is all is required to make a normal class a stateless session bean
23
Command Pattern
24
Dumbo Vs. Jumbo
Oh No! One more concept. I am fed up with this
guy!
25
Command Pattern
As Mr. Jumbo, said this is a very important concept to understand before we
move on
Let us try to explain this with an example
26
Command Pattern
27
Command Pattern
I do two important
things. Either I start It is my responsibility to
rotating or stop rotating either switch on the Fan
or switch off the Fan.
Don’t think that I am a
genius. You will
understand why I am
not
It is my responsibility to
either switch on or off I too do two important
the light. Like my peer things. Either I start
neither am I a genius glowing or stop glowing
28
Command Pattern
29
Command Pattern - Terminologies to Know
ON and OFF – These are the COMMANDS that the end user is interested
in
Switch (Fan’s and Light’s) – We are the INVOKERs of the command
30
Command Pattern - Terminologies to Know
ON and OFF – These are the COMMANDS that the end user is interested
in
Switch (Fan’s and Light’s) – We are the INVOKERs of the command
31
Dumbo Vs. Jumbo
Wait, before we go any further, what
problem are we trying to solve using
command pattern? Why should I use
command pattern? Without explaining this,
this guy is in his own world!!
32
How is the Command Pattern
Implemented?
Declare an interface called Command with a method called execute (These
are just names you can name them as you like)
Have implementations for each command:
– LightOnCommand
– LightOffCommand
– FanOnCommand
– FanOffCommand
Please note: The above implementations will NOT actually implement the
logic for various commands in their execute method. It will simply invoke
the business logic method of FAN or LIGHT
Define a class called Switch
– Constructor gets two command objects (one for on and one for Off)
– Have two public methods one for on and one for off, which simply
invokes the corresponding on / off methods of the command
33
Sample Code
class Fan {
public void startRotate() {
System.out.println("Fan is rotating");
}
public void stopRotate() {
System.out.println("Fan is not rotating");
}
}
class Light {
public void turnOn( ) {
System.out.println("Light is on ");
}
public void turnOff( ) {
System.out.println("Light is off");
}
}
34
Sample Code
class Switch {
private Command UpCommand, DownCommand;
public Switch( Command Up, Command Down) {
UpCommand = Up; // concrete Command registers itself with t
he invoker
DownCommand = Down;
}
void flipUp( ) { // invoker calls back concrete Command, which
executes the Command on the receiver
UpCommand . execute ( ) ;
}
void flipDown( ) {
DownCommand . execute ( );
}
}
35
Sample Code
public interface Command { class FanOffCommand implements Command {
public abstract void execute ( ); private Fan myFan;
} public FanOffCommand ( Fan F) {
class LightOnCommand implements myFan = F;
Command }
{ public void execute( ) {
private Light myLight; myFan . stopRotate( );
public LightOnCommand ( Light }
L) { }
myLight = L; public class TestCommand {
} public static void main(String[] args) {
public void execute( ) { Light testLight = new Light( );
myLight . turnOn( ); LightOnCommand testLOC = new
} LightOnCommand(testLight);
} LightOffCommand testLFC = new
class LightOffCommand implements LightOffCommand(testLight);
Command Switch testSwitch = new Switch( testLOC,testLFC);
{ testSwitch.flipUp( );
private Light myLight; testSwitch.flipDown( );
public LightOffCommand ( Light Fan testFan = new Fan( );
L) { FanOnCommand foc = newFanOnCommand(testFan);
myLight = L; FanOffCommand ffc = new FanOffCommand(testFan);
} Switch ts = new Switch( foc,ffc);
public void execute( ) { ts.flipUp( );
myLight . turnOff( ); ts.flipDown( );
} }
} }
36
Dumbo Vs. Jumbo
For the benefit of others, can you please
summarize the command pattern and its
usage
Yes Sir.
• As you can see from the above example, the Switch class does not
know any implementation logic of Fan and Light
• Because of the power of Interface and Call Back, everything seems
so hidden from the Switch
• The details are completely abstracted until the command reaches the
Fan and Light classes where the commands are actually implemented
37
The Easy Going Life of a Switch
38
Summary of Day 2
39
Session 2
Thank You !
40