Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w37 ms

2012-11-18T16:23:44Z

Sbhatta9: /* Adapter Pattern */

<big>''' Adapter pattern and the related patterns (Bridge, Decorator, Facade)'''</big> 

The adapter design pattern allows the user to make changes to the existing class with other class libraries without changing the code for the existing class. The Bridge, Decorator and the Facade pattern look somewhat similar to the adapter pattern but their intent is different and that intent is what separates the above patterns from each other.

=== Adapter Pattern ===

Adapter pattern plays an important role when you want to incompatible interfaces to work together. It sis generally used for third party code or code that we cannot modify. If such code uses an interface which is different from the interface we wish to use, adapter is the answer.The real world example for an adapter pattern is the travel power adapter.Different countries have different socket and plug configuration. So you can use an adapter to fit a plug into a socket that initially was not possible due to different interface designs.

==== Implementattion ====

===== Adapter implementation using inheritance =====

This method can be used when you have incompatible method that needs to be used in other class. Using inheritance a "is-a" relationship is established between the base class and super class. The new compatible methods will be contained in the inherited adapter class.

public class CylindricalSocket {
public String supply(String cylinStem1, String cylinStem1) {
System.out.println("Power power power...");
}
}

public class RectangularAdapter extends CylindricalSocket {
public String adapt(String rectaStem1, Sting rectaStem2) {
//some conversion logic
String cylinStem1 = rectaStem1;
String cylinStem2 = rectaStem2;
return supply(cylinStem1, cylinStem2);
}
}

public class RectangularPlug {
private String rectaStem1;
private String rectaStem2;
public getPower() {
RectangulrAdapter adapter = new RectangulrAdapter();
String power = adapter.adapt(rectaStem1, rectaStem2);
System.out.println(power);
}
}

===== Adapter implementation using composition =====

The other approach is to have a base class as an attribute in the adapter class. This creates an "has-a"relationship between the base class and the sub class.

public class CylindricalSocket {
public String supply(String cylinStem1, String cylinStem1) {
System.out.println("Power power power...");
}
}

public class RectangularAdapter {
private CylindricalSocket socket;

public String adapt(String rectaStem1, Sting rectaStem2) {
//some conversion logic
socket = new CylindricalSocket();
String cylinStem1 = rectaStem1;
String cylinStem2 = rectaStem2;
return socket.supply(cylinStem1, cylinStem2);
}
}

public class RectangularPlug {
private String rectaStem1;
private String rectaStem2;
public getPower() {
RectangulrAdapter adapter = new RectangulrAdapter();
String power = adapter.adapt(rectaStem1, rectaStem2);
System.out.println(power);
}
}

===== Composition or inheritance to implement Adapter Pattern? =====

* Composition is preferred over inheritance since using composition it is easy to change the behavior of a class.

===== Adapter pattern in Java Library=====
* java.io.InputStreamReader(InputStream)
* java.io.OutputStreamWriter(OutputStream)

=== Bridge Pattern ===
As stated by GoF a bridge design patterns intent is to “Decouple an abstraction from its implementation so that the two can vary independently”.

===== Elements of Bridge Design Pattern =====
* Abstraction: This is where the abstraction interface is defined.

For example: A Vehicle class which has a manufacture method.

* Refined Abstraction: Refined Abstraction extends the interface defined by Abstraction.

For example, a Car class or a Bike class which has a manufacture method which is more refined than the Vehicle class.

* Implementor: It defines the interface for the implementation classes. It defines the basic operation.

For example, the Workshop class acts as an implementor with the work() method.

* Concrete Implementation: This implements the Implementor interface and gives it a more concrete implementation.

For example the Produce and the Assemble class with the work() method provides the concrete implementation.

[[File:Bridge-Pattern.jpg|350 px|thumb|right|UML Diagram for Bridge-Pattern]]
[[File:WBP.jpg|350 px|thumb|left|Without Bridge-Pattern]][[File:bp.jpg|350 px|thumb|center|With Bridge-Pattern]]

 
 
 
 
 
 
 
 

===== Example code for Bridge pattern =====
Vehicle Interface

// abstraction in bridge pattern
abstract class Vehicle {
protected Workshop workShop1;
protected Workshop workShop2;

protected Vehicle(Workshop workShop1, Workshop workShop2) {
this.workShop1 = workShop1;
this.workShop2 = workShop2;
}

abstract public void manufacture();
}
Car class

//Refine abstraction 1 in bridge pattern
public class Car extends Vehicle {

public Car(Workshop workShop1, Workshop workShop2) {
super(workShop1, workShop2);
}

@Override
public void manufacture() {
System.out.print("Car ");
workShop1.work();
workShop2.work();

}

}
Bike Class

// Refine abstraction 2 in bridge pattern
public class Bike extends Vehicle {

public Bike(Workshop workShop1, Workshop workShop2) {
super(workShop1, workShop2);
}

@Override
public void manufacture() {
System.out.print("Bike ");
workShop1.work();
workShop2.work();
}

}
Workshop Interface

// Implementor for bridge pattern
public interface Workshop {
abstract public void work();
}

Produce Class

// Concrete implementation 1 for bridge pattern
public class Produce implements Workshop {

@Override
public void work() {
System.out.print("Produced");
}

}

Assemble Class
//Concrete implementation 2 for bridge pattern

public class Assemble implements Workshop {

@Override
public void work() {
System.out.println(" Assembled.");
}

}

Demonstration of bridge design pattern

public class BridgePattern {

public static void main(String[] args) {

Vehicle vehicle1 = new Car(new Produce(), new Assemble());
vehicle1.manufacture();
Vehicle vehicle2 = new Bike(new Produce(), new Assemble());
vehicle2.manufacture();

}
}

Output:
Car Produced Assembled.
Bike Produced Assembled.

===== Bridge vs Adapter pattern =====
* Two incompatable classes can be made to work together using adapter pattern.
* Bridge pattern creates two separate hierarchies by separating the abstraction from the implementation.

While the two patterns may seem similar according to the GoF- "Adapter makes things work after they're designed; Bridge makes them work before they are. [GoF, p219]".

The adapter pattern is useful when we have code that is either third party or maybe in house, over which we do not have any control and such code do not fit with the interface that we wish to use. In such a case we use either of two (delegation or inheritance) model of the adapter pattern to change the existing classes (which do not fit our interface) and cast them to our desired interface.

The bridge pattern on the other hand is something we implement upfront on classes that have orthogonal hierarchies. It provides a way to decouple the interface and the implementation in such a way that you don't get an insane number of classes. In bridge pattern we usually deal with classes that vary in their implementations a lot and we want to incorporate the functionality of the implementation classes as much as possible. Bridge pattern is many times implemented with the help adapter pattern to give the orthogonal hierarchies a common interface.

For example

We have a FileReader interface with two implementations. One that reads file from windows system and one that read Files from Linux systems. Now there are two more interface say MemoryMappedFiles and RADFiles. Now bridge pattern will help you in not having to write four classes MemoryMappedWindowsFileReader, MemoryMappedLinuxFileReader, RADWindowsFileReader, RADWindowsFileReader. Here is how

Use adapter pattern to adapt MemoryMappedFiles and RADFiles to a common interface (assuming both implementations have SpecialFile interface in common). Also WindowsFileReader and LinuxFileReader are two implementations of the FileReader interface.

public interface CrossPlatformSpecialPurposeFileReader{
public void readFile(); // used for adapting

}

SpecialWindowsFileReader extends WindowsFileReader implements CrossPlatformSpecialPurposeFileReader{
SpecialFile specialFile;

public SpecialWindowsFileReader(SpecialFile specialFile){
this.specialFile = specialFile;
}

public void readFile(){
byte fileBytes[] = this.read(); // read platform specific and convert to bytes
this.specialFile(fileBytes) // decouples from the filesystem specifics.
}
}

SpecialLinuxFileReader extends LinuxFileReader implements CrossPlatformSpecialPurposeFileReader{
SpecialFile specialFile;

public SpecialLinuxFileReader(SpecialFile specialFile){
this.specialFile = specialFile;
}

public void readFile(){
byte fileBytes[] = this.read(); // read platform specific and convert to bytes
this.specialFile(fileBytes) // decouples from the filesystem specifics.
}
}

// bridge pattern

public class Bridge{
public static void main(String args[]){
CrossPlatformSpecialPurposeFileReader specialFiles[] = new CrossPlatformSpecialPurposeFileReader[2];
specialFiles[0] = new SpecialWindowsFileReader(new MemoryMappedFiles());
specialFiles[1] = new SpecialLinuxFileReader(new RADFiles());
// deouples two orthogonal implementations under one interface.
for(CrossPlatformSpecialPurposeFileReader reader : specialFiles){
reader.readFile();
}
}
}

=== Decorator Pattern ===

The decorator pattern adds responsibility to an object dynamically. The decorator design pattern is used to extend the behavior of an object dynamically. In order to extend the behavior we have to construct an wrapper around the object. Inheritance is not feasible since it is applied to an entire class. With the decorator pattern it is possible to select any particular instance and modify its behavior leaving the other instances unmodified.

[[File:Decorator-Pattern.jpg|200 px|thumb|right|UML Diagram for Decorator-Pattern]]
==== Implementation of Decorator Pattern ====
First start with the interface which will be used by the class having the decoration design.
The example below explains how you first create a base ice cream and then decorate that ice cream by adding new toppings. The added topping changes the behavior of that ice cream. i.e. it gives the ice cream more taste.

The interface below contains an makeIcecream() method which has not been implemented yet.
public interface Icecream {
public String makeIcecream();
}

The SimpleIceCream Class provides an implementation to the makeIcecream() method. This is the class which acts as a base class on which decorations will be added.

public class SimpleIcecream implements Icecream {

@Override
public String makeIcecream() {
return "Base Icecream";
}

}
The class below is the crux of the design pattern. Here is where all the Decoration is actually provided to an instance of the object.It contains an attribute of type Icecream. Once the instance is assigned using the constructor the instance method will be invoked.

abstract class IcecreamDecorator implements Icecream {

protected Icecream specialIcecream;

public IcecreamDecorator(Icecream specialIcecream) {
this.specialIcecream = specialIcecream;
}

public String makeIcecream() {
return specialIcecream.makeIcecream();
}
}

The NuttyDecorator and HoneyDecorator are the two concrete classes that implement the abstract decorator class IcecreamDecorator.

public class NuttyDecorator extends IcecreamDecorator {

public NuttyDecorator(Icecream specialIcecream) {
super(specialIcecream);
}

public String makeIcecream() {
return specialIcecream.makeIcecream() + addNuts();
}

private String addNuts() {
return " + cruncy nuts";
}
}

public class HoneyDecorator extends IcecreamDecorator {

public HoneyDecorator(Icecream specialIcecream) {
super(specialIcecream);
}

public String makeIcecream() {
return specialIcecream.makeIcecream() + addHoney();
}

private String addHoney() {
return " + sweet honey";
}
}

===== Decorator pattern in Java Library=====
* java.io.BufferedReader;
* java.io.FileReader;
* java.io.Reader;

==== Adaptor Pattern vs Decorator Pattern====
* Adapter provides a different interface to its subject.
* Decorator provides an enhanced interface.

One important bit of difference between the two patterns is - In adapter pattern we adapt an existing interface to an interface that suits our needs. On the other hand in decorator pattern the aim is to enhance the existing interface such that the new interface can replace the existing interface without any changes in code.

http://sourcemaking.com/design_patterns/decorator

=== Facade Pattern ===

[[File:Wof.jpg|200 px|thumb|right|Without Facade-Pattern]]
[[File:Wf.jpg|200 px|thumb|right|With Facade-Pattern]]
[[File:FacadeUml.jpg|200 px|thumb|left|Microwave Design using Facade Pattern]]
GoF defines a facade design pattern as a pattern which , “Provides a unified interface to a set of interfaces in a subsystem. Facade Pattern defines a higher-level interface that makes the subsystem easier to use.”

Consider a software component. In order to get the job done this component might have to expose a of interfaces so that it can interact with other components in a process flow. Facade pattern simplifies this process by providing an unified interface. It builds an additional layer of abstraction over the existing abstract layer to simplify the process.

A microwave oven is made up of components like trasnformer, capacitor, magnetron, waveguide and some small other components. For a microwave to work all these different components needs to be executed in a sequence. If all these components had separate interfaces it would have been hard and complicated.Hence oven provides you buttons which can be considered as a facade. When you click on single button the job is done. That single button works as an abstraction layer between the user and the internal components.

==== Facade Pattern in java library ====
ExternalContext Class in java performs cookie management by using an facade pattern. It makes use of components such as HttpSession, ServletContext, javax.servlet.http.HttpServletRequest and javax.servlet.http.HttpServletResponse.

==== Facade Pattern vs Adapter Pattern ====
* Adapter pattern is to make an incompatible class work with other class where as facade provides programming comfort by providing an unified interface.
* Adapter Pattern using inheritance increases inter dependencies whereas facade pattern provides loose coupling
* Changing data to suit the interface of a subsystem is done by facade whereas changing the structure of a system is done by adapter pattern
* Facade increases subsystem independence and portability. This is not possible using the adapter pattern.

Facade defines a new interface, whereas Adapter uses an old interface. Adapter makes two existing interfaces work together as opposed to defining an entirely new one. Adapter and Facade are both wrappers; but they are different kinds of wrappers. The intent of Facade is to produce a simpler interface, and the intent of Adapter is to design to an existing interface. While Facade routinely wraps multiple objects and Adapter wraps a single object; Facade could front-end a single complex object and Adapter could wrap several legacy objects

CSC/ECE 517 Fall 2012/ch2b 2w37 ms

2012-11-18T15:27:26Z

Sbhatta9:

<big>''' Adapter pattern and the related patterns (Bridge, Decorator, Facade)'''</big> 

The adapter design pattern allows the user to make changes to the existing class with other class libraries without changing the code for the existing class. The Bridge, Decorator and the Facade pattern look somewhat similar to the adapter pattern but their intent is different and that intent is what separates the above patterns from each other.

=== Adapter Pattern ===

Adapter pattern plays an important role when you want to incompatible interfaces to work together.The real world example for an adapter pattern is the travel power adapter.Different countries have different socket and plug configuration. So you can use an adapter to fit a plug into a socket that initially was not possible due to different interface designs.

==== Implementattion ====

===== Adapter implementation using inheritance =====

This method can be used when you have incompatible method that needs to be used in other class. Using inheritance a "is-a" relationship is established between the base class and super class. The new compatible methods will be contained in the inherited adapter class.

public class CylindricalSocket {
public String supply(String cylinStem1, String cylinStem1) {
System.out.println("Power power power...");
}
}

public class RectangularAdapter extends CylindricalSocket {
public String adapt(String rectaStem1, Sting rectaStem2) {
//some conversion logic
String cylinStem1 = rectaStem1;
String cylinStem2 = rectaStem2;
return supply(cylinStem1, cylinStem2);
}
}

public class RectangularPlug {
private String rectaStem1;
private String rectaStem2;
public getPower() {
RectangulrAdapter adapter = new RectangulrAdapter();
String power = adapter.adapt(rectaStem1, rectaStem2);
System.out.println(power);
}
}

===== Adapter implementation using composition =====

The other approach is to have a base class as an attribute in the adapter class. This creates an "has-a"relationship between the base class and the sub class.

public class CylindricalSocket {
public String supply(String cylinStem1, String cylinStem1) {
System.out.println("Power power power...");
}
}

public class RectangularAdapter {
private CylindricalSocket socket;

public String adapt(String rectaStem1, Sting rectaStem2) {
//some conversion logic
socket = new CylindricalSocket();
String cylinStem1 = rectaStem1;
String cylinStem2 = rectaStem2;
return socket.supply(cylinStem1, cylinStem2);
}
}

public class RectangularPlug {
private String rectaStem1;
private String rectaStem2;
public getPower() {
RectangulrAdapter adapter = new RectangulrAdapter();
String power = adapter.adapt(rectaStem1, rectaStem2);
System.out.println(power);
}
}

===== Composition or inheritance to implement Adapter Pattern? =====

* Composition is preferred over inheritance since using composition it is easy to change the behavior of a class.

===== Adapter pattern in Java Library=====
* java.io.InputStreamReader(InputStream)
* java.io.OutputStreamWriter(OutputStream)

=== Bridge Pattern ===
As stated by GoF a bridge design patterns intent is to “Decouple an abstraction from its implementation so that the two can vary independently”.

===== Elements of Bridge Design Pattern =====
* Abstraction: This is where the abstraction interface is defined.

For example: A Vehicle class which has a manufacture method.

* Refined Abstraction: Refined Abstraction extends the interface defined by Abstraction.

For example, a Car class or a Bike class which has a manufacture method which is more refined than the Vehicle class.

* Implementor: It defines the interface for the implementation classes. It defines the basic operation.

For example, the Workshop class acts as an implementor with the work() method.

* Concrete Implementation: This implements the Implementor interface and gives it a more concrete implementation.

For example the Produce and the Assemble class with the work() method provides the concrete implementation.

[[File:Bridge-Pattern.jpg|350 px|thumb|right|UML Diagram for Bridge-Pattern]]
[[File:WBP.jpg|350 px|thumb|left|Without Bridge-Pattern]][[File:bp.jpg|350 px|thumb|center|With Bridge-Pattern]]

 
 
 
 
 
 
 
 

===== Example code for Bridge pattern =====
Vehicle Interface

// abstraction in bridge pattern
abstract class Vehicle {
protected Workshop workShop1;
protected Workshop workShop2;

protected Vehicle(Workshop workShop1, Workshop workShop2) {
this.workShop1 = workShop1;
this.workShop2 = workShop2;
}

abstract public void manufacture();
}
Car class

//Refine abstraction 1 in bridge pattern
public class Car extends Vehicle {

public Car(Workshop workShop1, Workshop workShop2) {
super(workShop1, workShop2);
}

@Override
public void manufacture() {
System.out.print("Car ");
workShop1.work();
workShop2.work();

}

}
Bike Class

// Refine abstraction 2 in bridge pattern
public class Bike extends Vehicle {

public Bike(Workshop workShop1, Workshop workShop2) {
super(workShop1, workShop2);
}

@Override
public void manufacture() {
System.out.print("Bike ");
workShop1.work();
workShop2.work();
}

}
Workshop Interface

// Implementor for bridge pattern
public interface Workshop {
abstract public void work();
}

Produce Class

// Concrete implementation 1 for bridge pattern
public class Produce implements Workshop {

@Override
public void work() {
System.out.print("Produced");
}

}

Assemble Class
//Concrete implementation 2 for bridge pattern

public class Assemble implements Workshop {

@Override
public void work() {
System.out.println(" Assembled.");
}

}

Demonstration of bridge design pattern

public class BridgePattern {

public static void main(String[] args) {

Vehicle vehicle1 = new Car(new Produce(), new Assemble());
vehicle1.manufacture();
Vehicle vehicle2 = new Bike(new Produce(), new Assemble());
vehicle2.manufacture();

}
}

Output:
Car Produced Assembled.
Bike Produced Assembled.

===== Bridge vs Adapter pattern =====
* Two incompatable classes can be made to work together using adapter pattern.
* Bridge pattern creates two separate hierarchies by separating the abstraction from the implementation.

While the two patterns may seem similar according to the GoF- "Adapter makes things work after they're designed; Bridge makes them work before they are. [GoF, p219]".

The adapter pattern is useful when we have code that is either third party or maybe in house, over which we do not have any control and such code do not fit with the interface that we wish to use. In such a case we use either of two (delegation or inheritance) model of the adapter pattern to change the existing classes (which do not fit our interface) and cast them to our desired interface.

The bridge pattern on the other hand is something we implement upfront on classes that have orthogonal hierarchies. It provides a way to decouple the interface and the implementation in such a way that you don't get an insane number of classes. In bridge pattern we usually deal with classes that vary in their implementations a lot and we want to incorporate the functionality of the implementation classes as much as possible. Bridge pattern is many times implemented with the help adapter pattern to give the orthogonal hierarchies a common interface.

For example

We have a FileReader interface with two implementations. One that reads file from windows system and one that read Files from Linux systems. Now there are two more interface say MemoryMappedFiles and RADFiles. Now bridge pattern will help you in not having to write four classes MemoryMappedWindowsFileReader, MemoryMappedLinuxFileReader, RADWindowsFileReader, RADWindowsFileReader. Here is how

Use adapter pattern to adapt MemoryMappedFiles and RADFiles to a common interface (assuming both implementations have SpecialFile interface in common). Also WindowsFileReader and LinuxFileReader are two implementations of the FileReader interface.

public interface CrossPlatformSpecialPurposeFileReader{
public void readFile(); // used for adapting

}

SpecialWindowsFileReader extends WindowsFileReader implements CrossPlatformSpecialPurposeFileReader{
SpecialFile specialFile;

public SpecialWindowsFileReader(SpecialFile specialFile){
this.specialFile = specialFile;
}

public void readFile(){
byte fileBytes[] = this.read(); // read platform specific and convert to bytes
this.specialFile(fileBytes) // decouples from the filesystem specifics.
}
}

SpecialLinuxFileReader extends LinuxFileReader implements CrossPlatformSpecialPurposeFileReader{
SpecialFile specialFile;

public SpecialLinuxFileReader(SpecialFile specialFile){
this.specialFile = specialFile;
}

public void readFile(){
byte fileBytes[] = this.read(); // read platform specific and convert to bytes
this.specialFile(fileBytes) // decouples from the filesystem specifics.
}
}

// bridge pattern

public class Bridge{
public static void main(String args[]){
CrossPlatformSpecialPurposeFileReader specialFiles[] = new CrossPlatformSpecialPurposeFileReader[2];
specialFiles[0] = new SpecialWindowsFileReader(new MemoryMappedFiles());
specialFiles[1] = new SpecialLinuxFileReader(new RADFiles());
// deouples two orthogonal implementations under one interface.
for(CrossPlatformSpecialPurposeFileReader reader : specialFiles){
reader.readFile();
}
}
}

=== Decorator Pattern ===

The decorator pattern adds responsibility to an object dynamically. The decorator design pattern is used to extend the behavior of an object dynamically. In order to extend the behavior we have to construct an wrapper around the object. Inheritance is not feasible since it is applied to an entire class. With the decorator pattern it is possible to select any particular instance and modify its behavior leaving the other instances unmodified.

[[File:Decorator-Pattern.jpg|200 px|thumb|right|UML Diagram for Decorator-Pattern]]
==== Implementation of Decorator Pattern ====
First start with the interface which will be used by the class having the decoration design.
The example below explains how you first create a base ice cream and then decorate that ice cream by adding new toppings. The added topping changes the behavior of that ice cream. i.e. it gives the ice cream more taste.

The interface below contains an makeIcecream() method which has not been implemented yet.
public interface Icecream {
public String makeIcecream();
}

The SimpleIceCream Class provides an implementation to the makeIcecream() method. This is the class which acts as a base class on which decorations will be added.

public class SimpleIcecream implements Icecream {

@Override
public String makeIcecream() {
return "Base Icecream";
}

}
The class below is the crux of the design pattern. Here is where all the Decoration is actually provided to an instance of the object.It contains an attribute of type Icecream. Once the instance is assigned using the constructor the instance method will be invoked.

abstract class IcecreamDecorator implements Icecream {

protected Icecream specialIcecream;

public IcecreamDecorator(Icecream specialIcecream) {
this.specialIcecream = specialIcecream;
}

public String makeIcecream() {
return specialIcecream.makeIcecream();
}
}

The NuttyDecorator and HoneyDecorator are the two concrete classes that implement the abstract decorator class IcecreamDecorator.

public class NuttyDecorator extends IcecreamDecorator {

public NuttyDecorator(Icecream specialIcecream) {
super(specialIcecream);
}

public String makeIcecream() {
return specialIcecream.makeIcecream() + addNuts();
}

private String addNuts() {
return " + cruncy nuts";
}
}

public class HoneyDecorator extends IcecreamDecorator {

public HoneyDecorator(Icecream specialIcecream) {
super(specialIcecream);
}

public String makeIcecream() {
return specialIcecream.makeIcecream() + addHoney();
}

private String addHoney() {
return " + sweet honey";
}
}

===== Decorator pattern in Java Library=====
* java.io.BufferedReader;
* java.io.FileReader;
* java.io.Reader;

==== Adaptor Pattern vs Decorator Pattern====
* Adapter provides a different interface to its subject.
* Decorator provides an enhanced interface.

One important bit of difference between the two patterns is - In adapter pattern we adapt an existing interface to an interface that suits our needs. On the other hand in decorator pattern the aim is to enhance the existing interface such that the new interface can replace the existing interface without any changes in code.

http://sourcemaking.com/design_patterns/decorator

=== Facade Pattern ===

[[File:Wof.jpg|200 px|thumb|right|Without Facade-Pattern]]
[[File:Wf.jpg|200 px|thumb|right|With Facade-Pattern]]
[[File:FacadeUml.jpg|200 px|thumb|left|Microwave Design using Facade Pattern]]
GoF defines a facade design pattern as a pattern which , “Provides a unified interface to a set of interfaces in a subsystem. Facade Pattern defines a higher-level interface that makes the subsystem easier to use.”

Consider a software component. In order to get the job done this component might have to expose a of interfaces so that it can interact with other components in a process flow. Facade pattern simplifies this process by providing an unified interface. It builds an additional layer of abstraction over the existing abstract layer to simplify the process.

A microwave oven is made up of components like trasnformer, capacitor, magnetron, waveguide and some small other components. For a microwave to work all these different components needs to be executed in a sequence. If all these components had separate interfaces it would have been hard and complicated.Hence oven provides you buttons which can be considered as a facade. When you click on single button the job is done. That single button works as an abstraction layer between the user and the internal components.

==== Facade Pattern in java library ====
ExternalContext Class in java performs cookie management by using an facade pattern. It makes use of components such as HttpSession, ServletContext, javax.servlet.http.HttpServletRequest and javax.servlet.http.HttpServletResponse.

==== Facade Pattern vs Adapter Pattern ====
* Adapter pattern is to make an incompatible class work with other class where as facade provides programming comfort by providing an unified interface.
* Adapter Pattern using inheritance increases inter dependencies whereas facade pattern provides loose coupling
* Changing data to suit the interface of a subsystem is done by facade whereas changing the structure of a system is done by adapter pattern
* Facade increases subsystem independence and portability. This is not possible using the adapter pattern.

Facade defines a new interface, whereas Adapter uses an old interface. Adapter makes two existing interfaces work together as opposed to defining an entirely new one. Adapter and Facade are both wrappers; but they are different kinds of wrappers. The intent of Facade is to produce a simpler interface, and the intent of Adapter is to design to an existing interface. While Facade routinely wraps multiple objects and Adapter wraps a single object; Facade could front-end a single complex object and Adapter could wrap several legacy objects

CSC/ECE 517 Fall 2012/ch2b 2w37 ms

2012-11-18T15:22:08Z

Sbhatta9:

<big>''' Adapter pattern and the related patterns (Bridge, Decorator, Facade)'''</big> 

The adapter design pattern allows the user to make changes to the existing class with other class libraries without changing the code for the existing class. The Bridge, Decorator and the Facade pattern look somewhat similar to the adapter pattern but their intent is different and that intent is what separates the above patterns from each other.

=== Adapter Pattern ===

Adapter pattern plays an important role when you want to incompatible interfaces to work together.The real world example for an adapter pattern is the travel power adapter.Different countries have different socket and plug configuration. So you can use an adapter to fit a plug into a socket that initially was not possible due to different interface designs.

==== Implementattion ====

===== Adapter implementation using inheritance =====

This method can be used when you have incompatible method that needs to be used in other class. Using inheritance a "is-a" relationship is established between the base class and super class. The new compatible methods will be contained in the inherited adapter class.

public class CylindricalSocket {
public String supply(String cylinStem1, String cylinStem1) {
System.out.println("Power power power...");
}
}

public class RectangularAdapter extends CylindricalSocket {
public String adapt(String rectaStem1, Sting rectaStem2) {
//some conversion logic
String cylinStem1 = rectaStem1;
String cylinStem2 = rectaStem2;
return supply(cylinStem1, cylinStem2);
}
}

public class RectangularPlug {
private String rectaStem1;
private String rectaStem2;
public getPower() {
RectangulrAdapter adapter = new RectangulrAdapter();
String power = adapter.adapt(rectaStem1, rectaStem2);
System.out.println(power);
}
}

===== Adapter implementation using composition =====

The other approach is to have a base class as an attribute in the adapter class. This creates an "has-a"relationship between the base class and the sub class.

public class CylindricalSocket {
public String supply(String cylinStem1, String cylinStem1) {
System.out.println("Power power power...");
}
}

public class RectangularAdapter {
private CylindricalSocket socket;

public String adapt(String rectaStem1, Sting rectaStem2) {
//some conversion logic
socket = new CylindricalSocket();
String cylinStem1 = rectaStem1;
String cylinStem2 = rectaStem2;
return socket.supply(cylinStem1, cylinStem2);
}
}

public class RectangularPlug {
private String rectaStem1;
private String rectaStem2;
public getPower() {
RectangulrAdapter adapter = new RectangulrAdapter();
String power = adapter.adapt(rectaStem1, rectaStem2);
System.out.println(power);
}
}

===== Composition or inheritance to implement Adapter Pattern? =====

* Composition is preferred over inheritance since using composition it is easy to change the behavior of a class.

===== Adapter pattern in Java Library=====
* java.io.InputStreamReader(InputStream)
* java.io.OutputStreamWriter(OutputStream)

=== Bridge Pattern ===
As stated by GoF a bridge design patterns intent is to “Decouple an abstraction from its implementation so that the two can vary independently”.

===== Elements of Bridge Design Pattern =====
* Abstraction: This is where the abstraction interface is defined.

For example: A Vehicle class which has a manufacture method.

* Refined Abstraction: Refined Abstraction extends the interface defined by Abstraction.

For example, a Car class or a Bike class which has a manufacture method which is more refined than the Vehicle class.

* Implementor: It defines the interface for the implementation classes. It defines the basic operation.

For example, the Workshop class acts as an implementor with the work() method.

* Concrete Implementation: This implements the Implementor interface and gives it a more concrete implementation.

For example the Produce and the Assemble class with the work() method provides the concrete implementation.

[[File:Bridge-Pattern.jpg|350 px|thumb|right|UML Diagram for Bridge-Pattern]]
[[File:WBP.jpg|350 px|thumb|left|Without Bridge-Pattern]][[File:bp.jpg|350 px|thumb|center|With Bridge-Pattern]]

 
 
 
 
 
 
 
 

===== Example code for Bridge pattern =====
Vehicle Interface

// abstraction in bridge pattern
abstract class Vehicle {
protected Workshop workShop1;
protected Workshop workShop2;

protected Vehicle(Workshop workShop1, Workshop workShop2) {
this.workShop1 = workShop1;
this.workShop2 = workShop2;
}

abstract public void manufacture();
}
Car class

//Refine abstraction 1 in bridge pattern
public class Car extends Vehicle {

public Car(Workshop workShop1, Workshop workShop2) {
super(workShop1, workShop2);
}

@Override
public void manufacture() {
System.out.print("Car ");
workShop1.work();
workShop2.work();

}

}
Bike Class

// Refine abstraction 2 in bridge pattern
public class Bike extends Vehicle {

public Bike(Workshop workShop1, Workshop workShop2) {
super(workShop1, workShop2);
}

@Override
public void manufacture() {
System.out.print("Bike ");
workShop1.work();
workShop2.work();
}

}
Workshop Interface

// Implementor for bridge pattern
public interface Workshop {
abstract public void work();
}

Produce Class

// Concrete implementation 1 for bridge pattern
public class Produce implements Workshop {

@Override
public void work() {
System.out.print("Produced");
}

}

Assemble Class
//Concrete implementation 2 for bridge pattern

public class Assemble implements Workshop {

@Override
public void work() {
System.out.println(" Assembled.");
}

}

Demonstration of bridge design pattern

public class BridgePattern {

public static void main(String[] args) {

Vehicle vehicle1 = new Car(new Produce(), new Assemble());
vehicle1.manufacture();
Vehicle vehicle2 = new Bike(new Produce(), new Assemble());
vehicle2.manufacture();

}
}

Output:
Car Produced Assembled.
Bike Produced Assembled.

===== Bridge vs Adapter pattern =====
* Two incompatable classes can be made to work together using adapter pattern.
* Bridge pattern creates two separate hierarchies by separating the abstraction from the implementation.

While the two patterns may seem similar according to the GoF- "Adapter makes things work after they're designed; Bridge makes them work before they are. [GoF, p219]".

The adapter pattern is useful when we have code that is either third party or maybe in house, over which we do not have any control and such code do not fit with the interface that we wish to use. In such a case we use either of two (delegation or inheritance) model of the adapter pattern to change the existing classes (which do not fit our interface) and cast them to our desired interface.

The bridge pattern on the other hand is something we implement upfront on classes that have orthogonal hierarchies. It provides a way to decouple the interface and the implementation in such a way that you don't get an insane number of classes. In bridge pattern we usually deal with classes that vary in their implementations a lot and we want to incorporate the functionality of the implementation classes as much as possible. Bridge pattern is many times implemented with the help adapter pattern to give the orthogonal hierarchies a common interface.

For example

We have a FileReader interface with two implementations. One that reads file from windows system and one that read Files from Linux systems. Now there are two more interface say MemoryMappedFiles and RADFiles. Now bridge pattern will help you in not having to write four classes MemoryMappedWindowsFileReader, MemoryMappedLinuxFileReader, RADWindowsFileReader, RADWindowsFileReader. Here is how

Use adapter pattern to adapt MemoryMappedFiles and RADFiles to a common interface (assuming both implementations have SpecialFile interface in common). Also WindowsFileReader and LinuxFileReader are two implementations of the FileReader interface.

public interface CrossPlatformSpecialPurposeFileReader{
public void readFile(); // used for adapting

}

SpecialWindowsFileReader extends WindowsFileReader implements CrossPlatformSpecialPurposeFileReader{
SpecialFile specialFile;

public SpecialWindowsFileReader(SpecialFile specialFile){
this.specialFile = specialFile;
}

public void readFile(){
byte fileBytes[] = this.read(); // read platform specific and convert to bytes
this.specialFile(fileBytes) // decouples from the filesystem specifics.
}
}

SpecialLinuxFileReader extends LinuxFileReader implements CrossPlatformSpecialPurposeFileReader{
SpecialFile specialFile;

public SpecialLinuxFileReader(SpecialFile specialFile){
this.specialFile = specialFile;
}

public void readFile(){
byte fileBytes[] = this.read(); // read platform specific and convert to bytes
this.specialFile(fileBytes) // decouples from the filesystem specifics.
}
}

// bridge pattern

public class Bridge{
public static void main(String args[]){
CrossPlatformSpecialPurposeFileReader specialFiles[] = new CrossPlatformSpecialPurposeFileReader[2];
specialFiles[0] = new SpecialWindowsFileReader(new MemoryMappedFiles());
specialFiles[1] = new SpecialLinuxFileReader(new RADFiles());
// deouples two orthogonal implementations under one interface.
for(CrossPlatformSpecialPurposeFileReader reader : specialFiles){
reader.readFile();
}
}
}

=== Decorator Pattern ===

The decorator pattern adds responsibility to an object dynamically. The decorator design pattern is used to extend the behavior of an object dynamically. In order to extend the behavior we have to construct an wrapper around the object. Inheritance is not feasible since it is applied to an entire class. With the decorator pattern it is possible to select any particular instance and modify its behavior leaving the other instances unmodified.

[[File:Decorator-Pattern.jpg|200 px|thumb|right|UML Diagram for Decorator-Pattern]]
==== Implementation of Decorator Pattern ====
First start with the interface which will be used by the class having the decoration design.
The example below explains how you first create a base ice cream and then decorate that ice cream by adding new toppings. The added topping changes the behavior of that ice cream. i.e. it gives the ice cream more taste.

The interface below contains an makeIcecream() method which has not been implemented yet.
public interface Icecream {
public String makeIcecream();
}

The SimpleIceCream Class provides an implementation to the makeIcecream() method. This is the class which acts as a base class on which decorations will be added.

public class SimpleIcecream implements Icecream {

@Override
public String makeIcecream() {
return "Base Icecream";
}

}
The class below is the crux of the design pattern. Here is where all the Decoration is actually provided to an instance of the object.It contains an attribute of type Icecream. Once the instance is assigned using the constructor the instance method will be invoked.

abstract class IcecreamDecorator implements Icecream {

protected Icecream specialIcecream;

public IcecreamDecorator(Icecream specialIcecream) {
this.specialIcecream = specialIcecream;
}

public String makeIcecream() {
return specialIcecream.makeIcecream();
}
}

The NuttyDecorator and HoneyDecorator are the two concrete classes that implement the abstract decorator class IcecreamDecorator.

public class NuttyDecorator extends IcecreamDecorator {

public NuttyDecorator(Icecream specialIcecream) {
super(specialIcecream);
}

public String makeIcecream() {
return specialIcecream.makeIcecream() + addNuts();
}

private String addNuts() {
return " + cruncy nuts";
}
}

public class HoneyDecorator extends IcecreamDecorator {

public HoneyDecorator(Icecream specialIcecream) {
super(specialIcecream);
}

public String makeIcecream() {
return specialIcecream.makeIcecream() + addHoney();
}

private String addHoney() {
return " + sweet honey";
}
}

===== Decorator pattern in Java Library=====
* java.io.BufferedReader;
* java.io.FileReader;
* java.io.Reader;

==== Adaptor Pattern vs Decorator Pattern====
* Adapter provides a different interface to its subject.
* Decorator provides an enhanced interface.

One important bit of difference between the two patterns is - In adapter pattern we adapt an existing interface to an interface that suits our needs. On the other hand in decorator pattern the aim is to enhance the existing interface such that the new interface can replace the existing interface without any changes in code.

http://sourcemaking.com/design_patterns/decorator

=== Facade Pattern ===

[[File:Wof.jpg|200 px|thumb|right|Without Facade-Pattern]]
[[File:Wf.jpg|200 px|thumb|right|With Facade-Pattern]]
[[File:FacadeUml.jpg|200 px|thumb|left|Microwave Design using Facade Pattern]]
GoF defines a facade design pattern as a pattern which , “Provides a unified interface to a set of interfaces in a subsystem. Facade Pattern defines a higher-level interface that makes the subsystem easier to use.”

Consider a software component. In order to get the job done this component might have to expose a of interfaces so that it can interact with other components in a process flow. Facade pattern simplifies this process by providing an unified interface. It builds an additional layer of abstraction over the existing abstract layer to simplify the process.

A microwave oven is made up of components like trasnformer, capacitor, magnetron, waveguide and some small other components. For a microwave to work all these different components needs to be executed in a sequence. If all these components had separate interfaces it would have been hard and complicated.Hence oven provides you buttons which can be considered as a facade. When you click on single button the job is done. That single button works as an abstraction layer between the user and the internal components.

==== Facade Pattern in java library ====
ExternalContext Class in java performs cookie management by using an facade pattern. It makes use of components such as HttpSession, ServletContext, javax.servlet.http.HttpServletRequest and javax.servlet.http.HttpServletResponse.

==== Facade Pattern vs Adapter Pattern ====
* Adapter pattern is to make an incompatible class work with other class where as facade provides programming comfort by providing an unified interface.
* Adapter Pattern using inheritance increases inter dependencies whereas facade pattern provides loose coupling
* Changing data to suit the interface of a subsystem is done by facade whereas changing the structure of a system is done by adapter pattern
* Facade increases subsystem independence and portability. This is not possible using the adapter pattern.

CSC/ECE 517 Fall 2012/ch2b 2w37 ms

2012-11-18T15:06:03Z

Sbhatta9:

<big>''' Adapter pattern and the related patterns (Bridge, Decorator, Facade)'''</big> 

The adapter design pattern allows the user to make changes to the existing class with other class libraries without changing the code for the existing class. The Bridge, Decorator and the Facade pattern look somewhat similar to the adapter pattern but their intent is different and that intent is what separates the above patterns from each other.

=== Adapter Pattern ===

Adapter pattern plays an important role when you want to incompatible interfaces to work together.The real world example for an adapter pattern is the travel power adapter.Different countries have different socket and plug configuration. So you can use an adapter to fit a plug into a socket that initially was not possible due to different interface designs.

==== Implementattion ====

===== Adapter implementation using inheritance =====

This method can be used when you have incompatible method that needs to be used in other class. Using inheritance a "is-a" relationship is established between the base class and super class. The new compatible methods will be contained in the inherited adapter class.

public class CylindricalSocket {
public String supply(String cylinStem1, String cylinStem1) {
System.out.println("Power power power...");
}
}

public class RectangularAdapter extends CylindricalSocket {
public String adapt(String rectaStem1, Sting rectaStem2) {
//some conversion logic
String cylinStem1 = rectaStem1;
String cylinStem2 = rectaStem2;
return supply(cylinStem1, cylinStem2);
}
}

public class RectangularPlug {
private String rectaStem1;
private String rectaStem2;
public getPower() {
RectangulrAdapter adapter = new RectangulrAdapter();
String power = adapter.adapt(rectaStem1, rectaStem2);
System.out.println(power);
}
}

===== Adapter implementation using composition =====

The other approach is to have a base class as an attribute in the adapter class. This creates an "has-a"relationship between the base class and the sub class.

public class CylindricalSocket {
public String supply(String cylinStem1, String cylinStem1) {
System.out.println("Power power power...");
}
}

public class RectangularAdapter {
private CylindricalSocket socket;

public String adapt(String rectaStem1, Sting rectaStem2) {
//some conversion logic
socket = new CylindricalSocket();
String cylinStem1 = rectaStem1;
String cylinStem2 = rectaStem2;
return socket.supply(cylinStem1, cylinStem2);
}
}

public class RectangularPlug {
private String rectaStem1;
private String rectaStem2;
public getPower() {
RectangulrAdapter adapter = new RectangulrAdapter();
String power = adapter.adapt(rectaStem1, rectaStem2);
System.out.println(power);
}
}

===== Composition or inheritance to implement Adapter Pattern? =====

* Composition is preferred over inheritance since using composition it is easy to change the behavior of a class.

===== Adapter pattern in Java Library=====
* java.io.InputStreamReader(InputStream)
* java.io.OutputStreamWriter(OutputStream)

=== Bridge Pattern ===
As stated by GoF a bridge design patterns intent is to “Decouple an abstraction from its implementation so that the two can vary independently”.

===== Elements of Bridge Design Pattern =====
* Abstraction: This is where the abstraction interface is defined.

For example: A Vehicle class which has a manufacture method.

* Refined Abstraction: Refined Abstraction extends the interface defined by Abstraction.

For example, a Car class or a Bike class which has a manufacture method which is more refined than the Vehicle class.

* Implementor: It defines the interface for the implementation classes. It defines the basic operation.

For example, the Workshop class acts as an implementor with the work() method.

* Concrete Implementation: This implements the Implementor interface and gives it a more concrete implementation.

For example the Produce and the Assemble class with the work() method provides the concrete implementation.

[[File:Bridge-Pattern.jpg|350 px|thumb|right|UML Diagram for Bridge-Pattern]]
[[File:WBP.jpg|350 px|thumb|left|Without Bridge-Pattern]][[File:bp.jpg|350 px|thumb|center|With Bridge-Pattern]]

 
 
 
 
 
 
 
 

===== Example code for Bridge pattern =====
Vehicle Interface

// abstraction in bridge pattern
abstract class Vehicle {
protected Workshop workShop1;
protected Workshop workShop2;

protected Vehicle(Workshop workShop1, Workshop workShop2) {
this.workShop1 = workShop1;
this.workShop2 = workShop2;
}

abstract public void manufacture();
}
Car class

//Refine abstraction 1 in bridge pattern
public class Car extends Vehicle {

public Car(Workshop workShop1, Workshop workShop2) {
super(workShop1, workShop2);
}

@Override
public void manufacture() {
System.out.print("Car ");
workShop1.work();
workShop2.work();

}

}
Bike Class

// Refine abstraction 2 in bridge pattern
public class Bike extends Vehicle {

public Bike(Workshop workShop1, Workshop workShop2) {
super(workShop1, workShop2);
}

@Override
public void manufacture() {
System.out.print("Bike ");
workShop1.work();
workShop2.work();
}

}
Workshop Interface

// Implementor for bridge pattern
public interface Workshop {
abstract public void work();
}

Produce Class

// Concrete implementation 1 for bridge pattern
public class Produce implements Workshop {

@Override
public void work() {
System.out.print("Produced");
}

}

Assemble Class
//Concrete implementation 2 for bridge pattern

public class Assemble implements Workshop {

@Override
public void work() {
System.out.println(" Assembled.");
}

}

Demonstration of bridge design pattern

public class BridgePattern {

public static void main(String[] args) {

Vehicle vehicle1 = new Car(new Produce(), new Assemble());
vehicle1.manufacture();
Vehicle vehicle2 = new Bike(new Produce(), new Assemble());
vehicle2.manufacture();

}
}

Output:
Car Produced Assembled.
Bike Produced Assembled.

===== Bridge vs Adapter pattern =====
* Two incompatable classes can be made to work together using adapter pattern.
* Bridge pattern creates two separate hierarchies by separating the abstraction from the implementation.

While the two patterns may seem similar according to the GoF- "Adapter makes things work after they're designed; Bridge makes them work before they are. [GoF, p219]".

The adapter pattern is useful when we have code that is either third party or maybe in house, over which we do not have any control and such code do not fit with the interface that we wish to use. In such a case we use either of two (delegation or inheritance) model of the adapter pattern to change the existing classes (which do not fit our interface) and cast them to our desired interface.

The bridge pattern on the other hand is something we implement upfront on classes that have orthogonal hierarchies. It provides a way to decouple the interface and the implementation in such a way that you don't get an insane number of classes. In bridge pattern we usually deal with classes that vary in their implementations a lot and we want to incorporate the functionality of the implementation classes as much as possible. Bridge pattern is many times implemented with the help adapter pattern to give the orthogonal hierarchies a common interface.

For example

We have a FileReader interface with two implementations. One that reads file from windows system and one that read Files from Linux systems. Now there are two more interface say MemoryMappedFiles and RADFiles. Now bridge pattern will help you in not having to write four classes MemoryMappedWindowsFileReader, MemoryMappedLinuxFileReader, RADWindowsFileReader, RADWindowsFileReader. Here is how

Use adapter pattern to adapt MemoryMappedFiles and RADFiles to a common interface (assuming both implementations have SpecialFile interface in common). Also WindowsFileReader and LinuxFileReader are two implementations of the FileReader interface.

public interface CrossPlatformSpecialPurposeFileReader{
public void readFile(); // used for adapting

}

SpecialWindowsFileReader extends WindowsFileReader implements CrossPlatformSpecialPurposeFileReader{
SpecialFile specialFile;

public SpecialWindowsFileReader(SpecialFile specialFile){
this.specialFile = specialFile;
}

public void readFile(){
byte fileBytes[] = this.read(); // read platform specific and convert to bytes
this.specialFile(fileBytes) // decouples from the filesystem specifics.
}
}

SpecialLinuxFileReader extends LinuxFileReader implements CrossPlatformSpecialPurposeFileReader{
SpecialFile specialFile;

public SpecialLinuxFileReader(SpecialFile specialFile){
this.specialFile = specialFile;
}

public void readFile(){
byte fileBytes[] = this.read(); // read platform specific and convert to bytes
this.specialFile(fileBytes) // decouples from the filesystem specifics.
}
}

// bridge pattern

public class Bridge{
public static void main(String args[]){
CrossPlatformSpecialPurposeFileReader specialFiles[] = new CrossPlatformSpecialPurposeFileReader[2];
specialFiles[0] = new SpecialWindowsFileReader(new MemoryMappedFiles());
specialFiles[1] = new SpecialLinuxFileReader(new RADFiles());
// deouples two orthogonal implementations under one interface.
for(CrossPlatformSpecialPurposeFileReader reader : specialFiles){
reader.readFile();
}
}
}

=== Decorator Pattern ===

The decorator pattern adds responsibility to an object dynamically. The decorator design pattern is used to extend the behavior of an object dynamically. In order to extend the behavior we have to construct an wrapper around the object. Inheritance is not feasible since it is applied to an entire class. With the decorator pattern it is possible to select any particular instance and modify its behavior leaving the other instances unmodified.

[[File:Decorator-Pattern.jpg|200 px|thumb|right|UML Diagram for Decorator-Pattern]]
==== Implementation of Decorator Pattern ====
First start with the interface which will be used by the class having the decoration design.
The example below explains how you first create a base ice cream and then decorate that ice cream by adding new toppings. The added topping changes the behavior of that ice cream. i.e. it gives the ice cream more taste.

The interface below contains an makeIcecream() method which has not been implemented yet.
public interface Icecream {
public String makeIcecream();
}

The SimpleIceCream Class provides an implementation to the makeIcecream() method. This is the class which acts as a base class on which decorations will be added.

public class SimpleIcecream implements Icecream {

@Override
public String makeIcecream() {
return "Base Icecream";
}

}
The class below is the crux of the design pattern. Here is where all the Decoration is actually provided to an instance of the object.It contains an attribute of type Icecream. Once the instance is assigned using the constructor the instance method will be invoked.

abstract class IcecreamDecorator implements Icecream {

protected Icecream specialIcecream;

public IcecreamDecorator(Icecream specialIcecream) {
this.specialIcecream = specialIcecream;
}

public String makeIcecream() {
return specialIcecream.makeIcecream();
}
}

The NuttyDecorator and HoneyDecorator are the two concrete classes that implement the abstract decorator class IcecreamDecorator.

public class NuttyDecorator extends IcecreamDecorator {

public NuttyDecorator(Icecream specialIcecream) {
super(specialIcecream);
}

public String makeIcecream() {
return specialIcecream.makeIcecream() + addNuts();
}

private String addNuts() {
return " + cruncy nuts";
}
}

public class HoneyDecorator extends IcecreamDecorator {

public HoneyDecorator(Icecream specialIcecream) {
super(specialIcecream);
}

public String makeIcecream() {
return specialIcecream.makeIcecream() + addHoney();
}

private String addHoney() {
return " + sweet honey";
}
}

===== Decorator pattern in Java Library=====
* java.io.BufferedReader;
* java.io.FileReader;
* java.io.Reader;

==== Adaptor Pattern vs Decorator Pattern====
* Adapter provides a different interface to its subject.
* Decorator provides an enhanced interface.

http://sourcemaking.com/design_patterns/decorator

=== Facade Pattern ===

[[File:Wof.jpg|200 px|thumb|right|Without Facade-Pattern]]
[[File:Wf.jpg|200 px|thumb|right|With Facade-Pattern]]
[[File:FacadeUml.jpg|200 px|thumb|left|Microwave Design using Facade Pattern]]
GoF defines a facade design pattern as a pattern which , “Provides a unified interface to a set of interfaces in a subsystem. Facade Pattern defines a higher-level interface that makes the subsystem easier to use.”

Consider a software component. In order to get the job done this component might have to expose a of interfaces so that it can interact with other components in a process flow. Facade pattern simplifies this process by providing an unified interface. It builds an additional layer of abstraction over the existing abstract layer to simplify the process.

A microwave oven is made up of components like trasnformer, capacitor, magnetron, waveguide and some small other components. For a microwave to work all these different components needs to be executed in a sequence. If all these components had separate interfaces it would have been hard and complicated.Hence oven provides you buttons which can be considered as a facade. When you click on single button the job is done. That single button works as an abstraction layer between the user and the internal components.

==== Facade Pattern in java library ====
ExternalContext Class in java performs cookie management by using an facade pattern. It makes use of components such as HttpSession, ServletContext, javax.servlet.http.HttpServletRequest and javax.servlet.http.HttpServletResponse.

==== Facade Pattern vs Adapter Pattern ====
* Adapter pattern is to make an incompatible class work with other class where as facade provides programming comfort by providing an unified interface.
* Adapter Pattern using inheritance increases inter dependencies whereas facade pattern provides loose coupling
* Changing data to suit the interface of a subsystem is done by facade whereas changing the structure of a system is done by adapter pattern
* Facade increases subsystem independence and portability. This is not possible using the adapter pattern.

CSC/ECE 517 Fall 2012/ch2b 2w37 ms

2012-11-18T15:04:38Z

Sbhatta9:

<big>''' Adapter pattern and the related patterns (Bridge, Decorator, Facade)'''</big> 

The adapter design pattern allows the user to make changes to the existing class with other class libraries without changing the code for the existing class. The Bridge, Decorator and the Facade pattern look somewhat similar to the adapter pattern but their intent is different and that intent is what separates the above patterns from each other.

=== Adapter Pattern ===

Adapter pattern plays an important role when you want to incompatible interfaces to work together.The real world example for an adapter pattern is the travel power adapter.Different countries have different socket and plug configuration. So you can use an adapter to fit a plug into a socket that initially was not possible due to different interface designs.

==== Implementattion ====

===== Adapter implementation using inheritance =====

This method can be used when you have incompatible method that needs to be used in other class. Using inheritance a "is-a" relationship is established between the base class and super class. The new compatible methods will be contained in the inherited adapter class.

public class CylindricalSocket {
public String supply(String cylinStem1, String cylinStem1) {
System.out.println("Power power power...");
}
}

public class RectangularAdapter extends CylindricalSocket {
public String adapt(String rectaStem1, Sting rectaStem2) {
//some conversion logic
String cylinStem1 = rectaStem1;
String cylinStem2 = rectaStem2;
return supply(cylinStem1, cylinStem2);
}
}

public class RectangularPlug {
private String rectaStem1;
private String rectaStem2;
public getPower() {
RectangulrAdapter adapter = new RectangulrAdapter();
String power = adapter.adapt(rectaStem1, rectaStem2);
System.out.println(power);
}
}

===== Adapter implementation using composition =====

The other approach is to have a base class as an attribute in the adapter class. This creates an "has-a"relationship between the base class and the sub class.

public class CylindricalSocket {
public String supply(String cylinStem1, String cylinStem1) {
System.out.println("Power power power...");
}
}

public class RectangularAdapter {
private CylindricalSocket socket;

public String adapt(String rectaStem1, Sting rectaStem2) {
//some conversion logic
socket = new CylindricalSocket();
String cylinStem1 = rectaStem1;
String cylinStem2 = rectaStem2;
return socket.supply(cylinStem1, cylinStem2);
}
}

public class RectangularPlug {
private String rectaStem1;
private String rectaStem2;
public getPower() {
RectangulrAdapter adapter = new RectangulrAdapter();
String power = adapter.adapt(rectaStem1, rectaStem2);
System.out.println(power);
}
}

===== Composition or inheritance to implement Adapter Pattern? =====

* Composition is preferred over inheritance since using composition it is easy to change the behavior of a class.

===== Adapter pattern in Java Library=====
* java.io.InputStreamReader(InputStream)
* java.io.OutputStreamWriter(OutputStream)

=== Bridge Pattern ===
As stated by GoF a bridge design patterns intent is to “Decouple an abstraction from its implementation so that the two can vary independently”.

===== Elements of Bridge Design Pattern =====
* Abstraction: This is where the abstraction interface is defined.

For example: A Vehicle class which has a manufacture method.

* Refined Abstraction: Refined Abstraction extends the interface defined by Abstraction.

For example, a Car class or a Bike class which has a manufacture method which is more refined than the Vehicle class.

* Implementor: It defines the interface for the implementation classes. It defines the basic operation.

For example, the Workshop class acts as an implementor with the work() method.

* Concrete Implementation: This implements the Implementor interface and gives it a more concrete implementation.

For example the Produce and the Assemble class with the work() method provides the concrete implementation.

[[File:Bridge-Pattern.jpg|350 px|thumb|right|UML Diagram for Bridge-Pattern]]
[[File:WBP.jpg|350 px|thumb|left|Without Bridge-Pattern]][[File:bp.jpg|350 px|thumb|center|With Bridge-Pattern]]

 
 
 
 
 
 
 
 

===== Example code for Bridge pattern =====
Vehicle Interface

// abstraction in bridge pattern
abstract class Vehicle {
protected Workshop workShop1;
protected Workshop workShop2;

protected Vehicle(Workshop workShop1, Workshop workShop2) {
this.workShop1 = workShop1;
this.workShop2 = workShop2;
}

abstract public void manufacture();
}
Car class

//Refine abstraction 1 in bridge pattern
public class Car extends Vehicle {

public Car(Workshop workShop1, Workshop workShop2) {
super(workShop1, workShop2);
}

@Override
public void manufacture() {
System.out.print("Car ");
workShop1.work();
workShop2.work();

}

}
Bike Class

// Refine abstraction 2 in bridge pattern
public class Bike extends Vehicle {

public Bike(Workshop workShop1, Workshop workShop2) {
super(workShop1, workShop2);
}

@Override
public void manufacture() {
System.out.print("Bike ");
workShop1.work();
workShop2.work();
}

}
Workshop Interface

// Implementor for bridge pattern
public interface Workshop {
abstract public void work();
}

Produce Class

// Concrete implementation 1 for bridge pattern
public class Produce implements Workshop {

@Override
public void work() {
System.out.print("Produced");
}

}

Assemble Class
//Concrete implementation 2 for bridge pattern

public class Assemble implements Workshop {

@Override
public void work() {
System.out.println(" Assembled.");
}

}

Demonstration of bridge design pattern

public class BridgePattern {

public static void main(String[] args) {

Vehicle vehicle1 = new Car(new Produce(), new Assemble());
vehicle1.manufacture();
Vehicle vehicle2 = new Bike(new Produce(), new Assemble());
vehicle2.manufacture();

}
}

Output:
Car Produced Assembled.
Bike Produced Assembled.

===== Bridge vs Adapter pattern =====
* Two incompatable classes can be made to work together using adapter pattern.
* Bridge pattern creates two separate hierarchies by separating the abstraction from the implementation.

While the two patterns may seem similar according to the GoF- "Adapter makes things work after they're designed; Bridge makes them work before they are. [GoF, p219]".

The adapter pattern is useful when we have code that is either third party or maybe in house, over which we do not have any control and such code do not fit with the interface that we wish to use. In such a case we use either of two (delegation or inheritance) model of the adapter pattern to change the existing classes (which do not fit our interface) and cast them to our desired interface.

The bridge pattern on the other hand is something we implement upfront on classes that have orthogonal hierarchies. It provides a way to decouple the interface and the implementation in such a way that you don't get an insane number of classes. In bridge pattern we usually deal with classes that vary in their implementations a lot and we want to incorporate the functionality of the implementation classes as much as possible. Bridge pattern is many times implemented with the help adapter pattern to give the orthogonal hierarchies a common interface.

For example

We have a FileReader interface with two implementations. One that reads file from windows system and one that read Files from Linux systems. Now there are two more interface say MemoryMappedFiles and RADFiles. Now bridge pattern will help you in not having to write four classes MemoryMappedWindowsFileReader, MemoryMappedLinuxFileReader, RADWindowsFileReader, RADWindowsFileReader. Here is how

Use adapter pattern to adapt MemoryMappedFiles and RADFiles to a common interface (assuming both implementations have SpecialFile interface in common). Also WindowsFileReader and LinuxFileReader are two implementations of the FileReader interface.

public interface CrossPlatformSpecialPurposeFileReader{
public void readFile(); // used for adapting

}

SpecialWindowsFileReader extends WindowsFileReader implements CrossPlatformSpecialPurposeFileReader{
SpecialFile specialFile;

public SpecialWindowsFileReader(SpecialFile specialFile){
this.specialFile = specialFile;
}

public void readFile(){
byte fileBytes[] = this.read(); // read platform specific and convert to bytes
this.specialFile(fileBytes) // decouples from the filesystem specifics.
}
}

SpecialLinuxFileReader extends LinuxFileReader implements CrossPlatformSpecialPurposeFileReader{
SpecialFile specialFile;

public SpecialLinuxFileReader(SpecialFile specialFile){
this.specialFile = specialFile;
}

public void readFile(){
byte fileBytes[] = this.read(); // read platform specific and convert to bytes
this.specialFile(fileBytes) // decouples from the filesystem specifics.
}
}

// bridge pattern

public class Bridge{
public static void main(String args[]){
CrossPlatformSpecialPurposeFileReader specialFiles[] = new CrossPlatformSpecialPurposeFileReader[2];
specialFiles[0] = new SpecialWindowsFileReader(new MemoryMappedFiles());
specialFiles[1] = new SpecialLinuxFileReader(new RADFiles());
// deouples two orthogonal implementations under one interface.
for(CrossPlatformSpecialPurposeFileReader reader : specialFiles){
reader.readFile();
}

}
}

=== Decorator Pattern ===

The decorator pattern adds responsibility to an object dynamically. The decorator design pattern is used to extend the behavior of an object dynamically. In order to extend the behavior we have to construct an wrapper around the object. Inheritance is not feasible since it is applied to an entire class. With the decorator pattern it is possible to select any particular instance and modify its behavior leaving the other instances unmodified.

[[File:Decorator-Pattern.jpg|200 px|thumb|right|UML Diagram for Decorator-Pattern]]
==== Implementation of Decorator Pattern ====
First start with the interface which will be used by the class having the decoration design.
The example below explains how you first create a base ice cream and then decorate that ice cream by adding new toppings. The added topping changes the behavior of that ice cream. i.e. it gives the ice cream more taste.

The interface below contains an makeIcecream() method which has not been implemented yet.
public interface Icecream {
public String makeIcecream();
}

The SimpleIceCream Class provides an implementation to the makeIcecream() method. This is the class which acts as a base class on which decorations will be added.

public class SimpleIcecream implements Icecream {

@Override
public String makeIcecream() {
return "Base Icecream";
}

}
The class below is the crux of the design pattern. Here is where all the Decoration is actually provided to an instance of the object.It contains an attribute of type Icecream. Once the instance is assigned using the constructor the instance method will be invoked.

abstract class IcecreamDecorator implements Icecream {

protected Icecream specialIcecream;

public IcecreamDecorator(Icecream specialIcecream) {
this.specialIcecream = specialIcecream;
}

public String makeIcecream() {
return specialIcecream.makeIcecream();
}
}

The NuttyDecorator and HoneyDecorator are the two concrete classes that implement the abstract decorator class IcecreamDecorator.

public class NuttyDecorator extends IcecreamDecorator {

public NuttyDecorator(Icecream specialIcecream) {
super(specialIcecream);
}

public String makeIcecream() {
return specialIcecream.makeIcecream() + addNuts();
}

private String addNuts() {
return " + cruncy nuts";
}
}

public class HoneyDecorator extends IcecreamDecorator {

public HoneyDecorator(Icecream specialIcecream) {
super(specialIcecream);
}

public String makeIcecream() {
return specialIcecream.makeIcecream() + addHoney();
}

private String addHoney() {
return " + sweet honey";
}
}

===== Decorator pattern in Java Library=====
* java.io.BufferedReader;
* java.io.FileReader;
* java.io.Reader;

==== Adaptor Pattern vs Decorator Pattern====
* Adapter provides a different interface to its subject.
* Decorator provides an enhanced interface.

http://sourcemaking.com/design_patterns/decorator

=== Facade Pattern ===

[[File:Wof.jpg|200 px|thumb|right|Without Facade-Pattern]]
[[File:Wf.jpg|200 px|thumb|right|With Facade-Pattern]]
[[File:FacadeUml.jpg|200 px|thumb|left|Microwave Design using Facade Pattern]]
GoF defines a facade design pattern as a pattern which , “Provides a unified interface to a set of interfaces in a subsystem. Facade Pattern defines a higher-level interface that makes the subsystem easier to use.”

Consider a software component. In order to get the job done this component might have to expose a of interfaces so that it can interact with other components in a process flow. Facade pattern simplifies this process by providing an unified interface. It builds an additional layer of abstraction over the existing abstract layer to simplify the process.

A microwave oven is made up of components like trasnformer, capacitor, magnetron, waveguide and some small other components. For a microwave to work all these different components needs to be executed in a sequence. If all these components had separate interfaces it would have been hard and complicated.Hence oven provides you buttons which can be considered as a facade. When you click on single button the job is done. That single button works as an abstraction layer between the user and the internal components.

==== Facade Pattern in java library ====
ExternalContext Class in java performs cookie management by using an facade pattern. It makes use of components such as HttpSession, ServletContext, javax.servlet.http.HttpServletRequest and javax.servlet.http.HttpServletResponse.

==== Facade Pattern vs Adapter Pattern ====
* Adapter pattern is to make an incompatible class work with other class where as facade provides programming comfort by providing an unified interface.
* Adapter Pattern using inheritance increases inter dependencies whereas facade pattern provides loose coupling
* Changing data to suit the interface of a subsystem is done by facade whereas changing the structure of a system is done by adapter pattern
* Facade increases subsystem independence and portability. This is not possible using the adapter pattern.

CSC/ECE 517 Fall 2012/ch1 1w19 sa

2012-09-15T00:33:43Z

Sbhatta9:

==Introduction==
'''Rails''' is a MVC (Model-View-Controller) based architecture for web development based on the Ruby language. Rails 2[http://guides.rubyonrails.org/2_3_release_notes.html] was released in December 2007. Initially Rails 2 supported Ruby 1.8[http://www.ruby-lang.org/en/news/2008/05/31/ruby-1-8-7-has-been-released/]. It now has been updated to support Ruby 1.9.1[http://www.ruby-lang.org/en/news/2009/01/30/ruby-1-9-1-released/]. Rails 3 which brings in many improvements over Rails 2 supports Ruby 1.9 and above. The current stable version of Rails is 3.2.8[http://rubyonrails.org/download] released on Aug 9, 2012.
This wikibook chapter focuses mainly on the differences of Rails 2 and Rails 3.

==Differences between Rails 2 and Rails 3==
==='''Unobtrusive Javascript'''[http://en.wikipedia.org/wiki/Unobtrusive_JavaScript]===
In previous versions of Rails, JavaScript was generated inline with HTML, causing ugly and somewhat brittle code.
As an example, Rails allows you to use its link_to method to generate a delete link for some object.

<%= link_to "Delete this Post", @post, :confirm => "Do you really want to delete this post?", :method => :delete %> 

Using this method in your view would generate the following in Rails 2:

<a href="/posts/6" onclick="if (confirm('Do you really want to delete this post?')) { var f = document.createElement('form');
f.style.display = 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action = this.href;
var m = document.createElement('input'); m.setAttribute('type', 'hidden'); m.setAttribute('name', '_method');
m.setAttribute('value', 'delete'); f.appendChild(m);f.submit(); };return false;">Delete this Post</a> 

Rails 3 would generate something much simpler:

<a href='/posts/6"' rel="nofollow" data-method="delete" data-confirm="Do you really want to delete this post?">Delete this Post</a> 

Rails 3 replaces all of the inline JavaScript with a couple of HTML5 attributes. All of the JavaScript event handlers to handle the actual confirmation box and deletion are stored in one central JavaScript file that is included with every rails project.

==='''No more dependency on only Prototype Javascript library'''===
One big advantage to this new method is that the JavaScript helpers are framework agnostic. Instead of being tied to the Prototype library like you were in Rails 2, you can now choose whatever JavaScript framework you like (Rails apps come with Prototype by default, but jQuery is now officially supported[https://github.com/rails/jquery-ujs].

==='''Improved Security'''===
Another awesome new feature of Rails 3 is that XSS[http://en.wikipedia.org/wiki/Cross-site_scripting] protection is now enabled by default. Rails 2 supported XSS protection through the use of the h method.

<%= h @comment.text %> 

The h method would escape html and JavaScript to ensure that no malicious client-side code was executed. This method worked great, but there was one problem: you had to actually remember to use the h method everywhere the user entered input was displayed. If you forgot even one place, then you were vulnerable to an XSS attack.
In Rails 3, all input is escaped by default, taking the burden off of the developer of having to remember to escape everywhere that malicious code might be present. For those times that you do want to allow unescaped data to appear in your view, you can use the raw method to tell Rails 3 not to escape the data.

<%= raw @comment.text %>

==='''New Query Engine'''===
Rails 3 includes a cool new query engine that makes it easier to get back the data you want and gives you more flexibility in your controller code. These changes show up in various places, but the most common case is fetching data in your controller. In Rails 2, you could use the find method to retrieve the data you were looking for, passing in arguments to specify conditions, grouping, limits, and any other query information. For example:

@posts = Post.find(:all, :conditions => [ "category IN (?)", categories], :limit => 10, :order => "created_on DESC")

finds the first ten posts within some specified categories ordered by the creation time.

In Rails 3, each of the passed in parameters has its own method, which can be chained together to get the same results.

@posts = Post.where([ "category IN (?)", categories]).order("created_on DESC").limit(10)

The query is not actually executed until the data is needed; so these methods can even be used across multiple statements.

@posts = Post.where([ "category IN (?)", categories])
if(condition_a)
@posts = @posts.where(['approved=?', true])
else
@posts = @posts.where(['approved=?', false])
End

This is only a simple example, but should provide you with an idea of some of the ways this new syntax can be more useful.

==='''Easier Email'''===
The ActionMailer module has been rewritten to make it a lot easier for your application to send email in Rails 3.

'''1-Default Setting'''
In Rails, a Mailer is a class that can have many methods, each of which generally configure and send an email. Previously, you had to set all of the parameters for each email separately in each method.

class UserMailer < ActionMailer::Base
def welcome_email(user)
from "system@example.com" # other paramters
end
def password_reset(user)
from "system@example.com"
# other parameters
end
end

In Rails 3, you can specify defaults that can be optionally overwritten in each method.

class UserMailer < ActionMailer::Base
default :from => 'no-reply@example.com',
:return_path => 'system@example.com'

def welcome_email(user)
# no need to specify from parameter
end
end

'''2-Cleaner API'''
Previous versions of Rails required you to send email using special methods that were dynamically created by ActionMailer. For instance, if you wanted to deliver the welcome email in the example above, you would need to call:

UserMailer.deliver_welcome_email(@user)

ln Rails 3, you can just call

UserMailer.welcome_email(@user).deliver 

This makes more sense semantically, and additionally allows you to retrieve and manipulate the Mail object before delivering the email.

==='''Dependency Management'''===
One of the strengths of the Ruby on Rails framework is the plethora of gems available for use by developers. Whether it's authentication[https://github.com/binarylogic/authlogic],
handling financial[http://activemerchant.org/] transactions[https://github.com/thoughtbot/paperclip], handling file uploads, or nearly anything else, chances are a gem exists to help with your problem.

Issues can arise, however, if your gems require other gems, or developers are on different environments, among other things. To help solve these types of
situations, Rails 3 adds the Bundler[http://gembundler.com/] gem to help manage your dependencies. Using Bundler in Rails 3 is extremely simple; add a line for each gem you
require in your Gemfile, a file included in the root of each of your applications.

gem 'authlogic'
Once you've included all your gems, run:

bundle install

and Bundler will download and configure all of the gems and their dependencies that you need for the project.
Bundler also allows you to specify certain gems to only be configured in certain environments (development vs production vs testing).
These are only a few of the many changes included in Ruby on Rails 3. Many of the old APIs still work in Rails, even if they've been deprecated, to make it easier to update.

==='''ActiveRecord finder methods'''===
In Rails 2

User.find(:all, : order => "created_at desc", :limit => 5) 

Rails 3 looks at the hash of options that is being passed to find(:all, : order, and :limit) and replace each item in the hash with an equivalent method.
Rails 3 has a new API for the dynamic fiders

where, having, select, group, order, limit, offset, joins, includes, ...

So, in Rails 3 it becomes

User.order("created_at desc").limit(5)

==='''Active Record Validations'''===
There sre separate validations in Rails 2

validates_presence_of :username

validates_uniqueness_of :username

validates_length_of :email, :maximum => 40 

In Rails 3 these can be clubbed together

validates :email, :presence => true,

:uniqueness => true,

:length => {:maximum => 30}

==References==
[http://guides.rubyonrails.org/3_0_release_notes.html Rails 3 Documentation]

[http://guides.rubyonrails.org/2_3_release_notes.html Rails 2 Documentation]

[http://api.rubyonrails.org/ Rails API]

[http://guides.rubyonrails.org/3_0_release_notes.html#mail-extraction Rails Mailer]

CSC/ECE 517 Fall 2012/ch1 1w19 sa

2012-09-15T00:32:51Z

Sbhatta9:

==Introduction==
'''Rails''' is a MVC (Model-View-Controller) based architecture for web development based on the Ruby language. Rails 2[http://guides.rubyonrails.org/2_3_release_notes.html] was released in December 2007. Initially Rails 2 supported Ruby 1.8[http://www.ruby-lang.org/en/news/2008/05/31/ruby-1-8-7-has-been-released/]. It now has been updated to support Ruby 1.9.1[http://www.ruby-lang.org/en/news/2009/01/30/ruby-1-9-1-released/]. Rails 3 which brings in many improvements over Rails 2 supports Ruby 1.9 and above. The current stable version of Rails is 3.2.8[http://rubyonrails.org/download] released on Aug 9, 2012.
This wikibook chapter focuses mainly on the differences of Rails 2 and Rails 3.

==Differences between Rails 2 and Rails 3==
==='''Unobtrusive Javascript'''[http://en.wikipedia.org/wiki/Unobtrusive_JavaScript]===
In previous versions of Rails, JavaScript was generated inline with HTML, causing ugly and somewhat brittle code.
As an example, Rails allows you to use its link_to method to generate a delete link for some object.

<%= link_to "Delete this Post", @post, :confirm => "Do you really want to delete this post?", :method => :delete %> 

Using this method in your view would generate the following in Rails 2:

<a href="/posts/6" onclick="if (confirm('Do you really want to delete this post?')) { var f = document.createElement('form');
f.style.display = 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action = this.href;
var m = document.createElement('input'); m.setAttribute('type', 'hidden'); m.setAttribute('name', '_method');
m.setAttribute('value', 'delete'); f.appendChild(m);f.submit(); };return false;">Delete this Post</a> 

Rails 3 would generate something much simpler:

<a href='/posts/6"' rel="nofollow" data-method="delete" data-confirm="Do you really want to delete this post?">Delete this Post</a> 

Rails 3 replaces all of the inline JavaScript with a couple of HTML5 attributes. All of the JavaScript event handlers to handle the actual confirmation box and deletion are stored in one central JavaScript file that is included with every rails project.

==='''No more dependency on only Prototype Javascript library'''===
One big advantage to this new method is that the JavaScript helpers are framework agnostic. Instead of being tied to the Prototype library like you were in Rails 2, you can now choose whatever JavaScript framework you like (Rails apps come with Prototype by default, but jQuery is now officially supported[https://github.com/rails/jquery-ujs].

==='''Improved Security'''===
Another awesome new feature of Rails 3 is that XSS[http://en.wikipedia.org/wiki/Cross-site_scripting] protection is now enabled by default. Rails 2 supported XSS protection through the use of the h method.
<%= h @comment.text %>
The h method would escape html and JavaScript to ensure that no malicious client-side code was executed. This method worked great, but there was one problem: you had to actually remember to use the h method everywhere the user entered input was displayed. If you forgot even one place, then you were vulnerable to an XSS attack.
In Rails 3, all input is escaped by default, taking the burden off of the developer of having to remember to escape everywhere that malicious code might be present. For those times that you do want to allow unescaped data to appear in your view, you can use the raw method to tell Rails 3 not to escape the data.

<%= raw @comment.text %>

==='''New Query Engine'''===
Rails 3 includes a cool new query engine that makes it easier to get back the data you want and gives you more flexibility in your controller code. These changes show up in various places, but the most common case is fetching data in your controller. In Rails 2, you could use the find method to retrieve the data you were looking for, passing in arguments to specify conditions, grouping, limits, and any other query information. For example:

@posts = Post.find(:all, :conditions => [ "category IN (?)", categories], :limit => 10, :order => "created_on DESC")

finds the first ten posts within some specified categories ordered by the creation time.

In Rails 3, each of the passed in parameters has its own method, which can be chained together to get the same results.

@posts = Post.where([ "category IN (?)", categories]).order("created_on DESC").limit(10)

The query is not actually executed until the data is needed; so these methods can even be used across multiple statements.

@posts = Post.where([ "category IN (?)", categories])
if(condition_a)
@posts = @posts.where(['approved=?', true])
else
@posts = @posts.where(['approved=?', false])
End

This is only a simple example, but should provide you with an idea of some of the ways this new syntax can be more useful.

==='''Easier Email'''===
The ActionMailer module has been rewritten to make it a lot easier for your application to send email in Rails 3.

'''1-Default Setting'''
In Rails, a Mailer is a class that can have many methods, each of which generally configure and send an email. Previously, you had to set all of the parameters for each email separately in each method.

class UserMailer < ActionMailer::Base
def welcome_email(user)
from "system@example.com" # other paramters
end
def password_reset(user)
from "system@example.com"
# other parameters
end
end

In Rails 3, you can specify defaults that can be optionally overwritten in each method.

class UserMailer < ActionMailer::Base
default :from => 'no-reply@example.com',
:return_path => 'system@example.com'

def welcome_email(user)
# no need to specify from parameter
end
end

'''2-Cleaner API'''
Previous versions of Rails required you to send email using special methods that were dynamically created by ActionMailer. For instance, if you wanted to deliver the welcome email in the example above, you would need to call:

UserMailer.deliver_welcome_email(@user)

ln Rails 3, you can just call

UserMailer.welcome_email(@user).deliver 

This makes more sense semantically, and additionally allows you to retrieve and manipulate the Mail object before delivering the email.

==='''Dependency Management'''===
One of the strengths of the Ruby on Rails framework is the plethora of gems available for use by developers. Whether it's authentication[https://github.com/binarylogic/authlogic],
handling financial[http://activemerchant.org/] transactions[https://github.com/thoughtbot/paperclip], handling file uploads, or nearly anything else, chances are a gem exists to help with your problem.

Issues can arise, however, if your gems require other gems, or developers are on different environments, among other things. To help solve these types of
situations, Rails 3 adds the Bundler[http://gembundler.com/] gem to help manage your dependencies. Using Bundler in Rails 3 is extremely simple; add a line for each gem you
require in your Gemfile, a file included in the root of each of your applications.

gem 'authlogic'
Once you've included all your gems, run:

bundle install

and Bundler will download and configure all of the gems and their dependencies that you need for the project.
Bundler also allows you to specify certain gems to only be configured in certain environments (development vs production vs testing).
These are only a few of the many changes included in Ruby on Rails 3. Many of the old APIs still work in Rails, even if they've been deprecated, to make it easier to update.

==='''ActiveRecord finder methods'''===
In Rails 2

User.find(:all, : order => "created_at desc", :limit => 5) 

Rails 3 looks at the hash of options that is being passed to find(:all, : order, and :limit) and replace each item in the hash with an equivalent method.
Rails 3 has a new API for the dynamic fiders

where, having, select, group, order, limit, offset, joins, includes, ...

So, in Rails 3 it becomes

User.order("created_at desc").limit(5)

==='''Active Record Validations'''===
There sre separate validations in Rails 2

validates_presence_of :username

validates_uniqueness_of :username

validates_length_of :email, :maximum => 40 

In Rails 3 these can be clubbed together

validates :email, :presence => true,

:uniqueness => true,

:length => {:maximum => 30}

==References==
[http://guides.rubyonrails.org/3_0_release_notes.html Rails 3 Documentation]

[http://guides.rubyonrails.org/2_3_release_notes.html Rails 2 Documentation]

[http://api.rubyonrails.org/ Rails API]

[http://guides.rubyonrails.org/3_0_release_notes.html#mail-extraction Rails Mailer]

CSC/ECE 517 Fall 2012/ch1 1w19 sa

2012-09-15T00:30:39Z

Sbhatta9:

==Introduction==
'''Rails''' is a MVC (Model-View-Controller) based architecture for web development based on the Ruby language. Rails 2[http://guides.rubyonrails.org/2_3_release_notes.html] was released in December 2007. Initially Rails 2 supported Ruby 1.8[http://www.ruby-lang.org/en/news/2008/05/31/ruby-1-8-7-has-been-released/]. It now has been updated to support Ruby 1.9.1[http://www.ruby-lang.org/en/news/2009/01/30/ruby-1-9-1-released/]. Rails 3 which brings in many improvements over Rails 2 supports Ruby 1.9 and above. The current stable version of Rails is 3.2.8[http://rubyonrails.org/download] released on Aug 9, 2012.
This wikibook chapter focuses mainly on the differences of Rails 2 and Rails 3.

==Differences between Rails 2 and Rails 3==
==='''Unobtrusive Javascript'''[http://en.wikipedia.org/wiki/Unobtrusive_JavaScript]===
In previous versions of Rails, JavaScript was generated inline with HTML, causing ugly and somewhat brittle code.
As an example, Rails allows you to use its link_to method to generate a delete link for some object.

<%= link_to "Delete this Post", @post, :confirm => "Do you really want to delete this post?", :method => :delete %>

Using this method in your view would generate the following in Rails 2:

<a href="/posts/6" onclick="if (confirm('Do you really want to delete this post?')) { var f = document.createElement('form');
f.style.display = 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action = this.href;
var m = document.createElement('input'); m.setAttribute('type', 'hidden'); m.setAttribute('name', '_method');
m.setAttribute('value', 'delete'); f.appendChild(m);f.submit(); };return false;">Delete this Post</a>

Rails 3 would generate something much simpler:

<a href='/posts/6"' rel="nofollow" data-method="delete" data-confirm="Do you really want to delete this post?">Delete this Post</a>

Rails 3 replaces all of the inline JavaScript with a couple of HTML5 attributes. All of the JavaScript event handlers to handle the actual confirmation box and deletion are stored in one central JavaScript file that is included with every rails project.

==='''No more dependency on only Prototype Javascript library'''===
One big advantage to this new method is that the JavaScript helpers are framework agnostic. Instead of being tied to the Prototype library like you were in Rails 2, you can now choose whatever JavaScript framework you like (Rails apps come with Prototype by default, but jQuery is now officially supported[https://github.com/rails/jquery-ujs].

==='''Improved Security'''===
Another awesome new feature of Rails 3 is that XSS[http://en.wikipedia.org/wiki/Cross-site_scripting] protection is now enabled by default. Rails 2 supported XSS protection through the use of the h method.
<%= h @comment.text %>
The h method would escape html and JavaScript to ensure that no malicious client-side code was executed. This method worked great, but there was one problem: you had to actually remember to use the h method everywhere the user entered input was displayed. If you forgot even one place, then you were vulnerable to an XSS attack.
In Rails 3, all input is escaped by default, taking the burden off of the developer of having to remember to escape everywhere that malicious code might be present. For those times that you do want to allow unescaped data to appear in your view, you can use the raw method to tell Rails 3 not to escape the data.

<%= raw @comment.text %>

==='''New Query Engine'''===
Rails 3 includes a cool new query engine that makes it easier to get back the data you want and gives you more flexibility in your controller code. These changes show up in various places, but the most common case is fetching data in your controller. In Rails 2, you could use the find method to retrieve the data you were looking for, passing in arguments to specify conditions, grouping, limits, and any other query information. For example:

@posts = Post.find(:all, :conditions => [ "category IN (?)", categories], :limit => 10, :order => "created_on DESC")

finds the first ten posts within some specified categories ordered by the creation time.

In Rails 3, each of the passed in parameters has its own method, which can be chained together to get the same results.

@posts = Post.where([ "category IN (?)", categories]).order("created_on DESC").limit(10)

The query is not actually executed until the data is needed; so these methods can even be used across multiple statements.

@posts = Post.where([ "category IN (?)", categories])
if(condition_a)
@posts = @posts.where(['approved=?', true])
else
@posts = @posts.where(['approved=?', false])
End

This is only a simple example, but should provide you with an idea of some of the ways this new syntax can be more useful.

==='''Easier Email'''===
The ActionMailer module has been rewritten to make it a lot easier for your application to send email in Rails 3.

'''1-Default Setting'''
In Rails, a Mailer is a class that can have many methods, each of which generally configure and send an email. Previously, you had to set all of the parameters for each email separately in each method.

class UserMailer < ActionMailer::Base
def welcome_email(user)
from "system@example.com" # other paramters
end
def password_reset(user)
from "system@example.com"
# other parameters
end
end

In Rails 3, you can specify defaults that can be optionally overwritten in each method.

class UserMailer < ActionMailer::Base
default :from => 'no-reply@example.com',
:return_path => 'system@example.com'

def welcome_email(user)
# no need to specify from parameter
end
end

'''2-Cleaner API'''
Previous versions of Rails required you to send email using special methods that were dynamically created by ActionMailer. For instance, if you wanted to deliver the welcome email in the example above, you would need to call:

UserMailer.deliver_welcome_email(@user)

ln Rails 3, you can just call

UserMailer.welcome_email(@user).deliver 

This makes more sense semantically, and additionally allows you to retrieve and manipulate the Mail object before delivering the email.

==='''Dependency Management'''===
One of the strengths of the Ruby on Rails framework is the plethora of gems available for use by developers. Whether it's authentication[https://github.com/binarylogic/authlogic],
handling financial[http://activemerchant.org/] transactions[https://github.com/thoughtbot/paperclip], handling file uploads, or nearly anything else, chances are a gem exists to help with your problem.

Issues can arise, however, if your gems require other gems, or developers are on different environments, among other things. To help solve these types of
situations, Rails 3 adds the Bundler[http://gembundler.com/] gem to help manage your dependencies. Using Bundler in Rails 3 is extremely simple; add a line for each gem you
require in your Gemfile, a file included in the root of each of your applications.

gem 'authlogic'
Once you've included all your gems, run:

bundle install

and Bundler will download and configure all of the gems and their dependencies that you need for the project.
Bundler also allows you to specify certain gems to only be configured in certain environments (development vs production vs testing).
These are only a few of the many changes included in Ruby on Rails 3. Many of the old APIs still work in Rails, even if they've been deprecated, to make it easier to update.

==='''ActiveRecord finder methods'''===
In Rails 2

User.find(:all, : order => "created_at desc", :limit => 5) 

Rails 3 looks at the hash of options that is being passed to find(:all, : order, and :limit) and replace each item in the hash with an equivalent method.
Rails 3 has a new API for the dynamic fiders

where, having, select, group, order, limit, offset, joins, includes, ...

So, in Rails 3 it becomes

User.order("created_at desc").limit(5)

==='''Active Record Validations'''===
There sre separate validations in Rails 2

validates_presence_of :username

validates_uniqueness_of :username

validates_length_of :email, :maximum => 40 

In Rails 3 these can be clubbed together

validates :email, :presence => true,

:uniqueness => true,

:length => {:maximum => 30}

==References==
[http://guides.rubyonrails.org/3_0_release_notes.html Rails 3 Documentation]

[http://guides.rubyonrails.org/2_3_release_notes.html Rails 2 Documentation]

[http://api.rubyonrails.org/ Rails API]

[http://guides.rubyonrails.org/3_0_release_notes.html#mail-extraction Rails Mailer]

CSC/ECE 517 Fall 2012/ch1 1w19 sa

2012-09-15T00:29:59Z

Sbhatta9:

==Introduction==
'''Rails''' is a MVC (Model-View-Controller) based architecture for web development based on the Ruby language. Rails 2[http://guides.rubyonrails.org/2_3_release_notes.html] was released in December 2007. Initially Rails 2 supported Ruby 1.8[http://www.ruby-lang.org/en/news/2008/05/31/ruby-1-8-7-has-been-released/]. It now has been updated to support Ruby 1.9.1[http://www.ruby-lang.org/en/news/2009/01/30/ruby-1-9-1-released/]. Rails 3 which brings in many improvements over Rails 2 supports Ruby 1.9 and above. The current stable version of Rails is 3.2.8[http://rubyonrails.org/download] released on Aug 9, 2012.
This wikibook chapter focuses mainly on the differences of Rails 2 and Rails 3.

==Differences between Rails 2 and Rails 3==
==='''Unobtrusive Javascript'''[http://en.wikipedia.org/wiki/Unobtrusive_JavaScript]===
In previous versions of Rails, JavaScript was generated inline with HTML, causing ugly and somewhat brittle code.
As an example, Rails allows you to use its link_to method to generate a delete link for some object.

<%= link_to "Delete this Post", @post, :confirm => "Do you really want to delete this post?", :method => :delete %>

Using this method in your view would generate the following in Rails 2:
<a href="/posts/6" onclick="if (confirm('Do you really want to delete this post?')) { var f = document.createElement('form');
f.style.display = 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action = this.href;
var m = document.createElement('input'); m.setAttribute('type', 'hidden'); m.setAttribute('name', '_method');
m.setAttribute('value', 'delete'); f.appendChild(m);f.submit(); };return false;">Delete this Post</a>

Rails 3 would generate something much simpler:

<a href='/posts/6"' rel="nofollow" data-method="delete" data-confirm="Do you really want to delete this post?">Delete this Post</a>

Rails 3 replaces all of the inline JavaScript with a couple of HTML5 attributes. All of the JavaScript event handlers to handle the actual confirmation box and deletion are stored in one central JavaScript file that is included with every rails project.

==='''No more dependency on only Prototype Javascript library'''===
One big advantage to this new method is that the JavaScript helpers are framework agnostic. Instead of being tied to the Prototype library like you were in Rails 2, you can now choose whatever JavaScript framework you like (Rails apps come with Prototype by default, but jQuery is now officially supported[https://github.com/rails/jquery-ujs].

==='''Improved Security'''===
Another awesome new feature of Rails 3 is that XSS[http://en.wikipedia.org/wiki/Cross-site_scripting] protection is now enabled by default. Rails 2 supported XSS protection through the use of the h method.
<%= h @comment.text %>
The h method would escape html and JavaScript to ensure that no malicious client-side code was executed. This method worked great, but there was one problem: you had to actually remember to use the h method everywhere the user entered input was displayed. If you forgot even one place, then you were vulnerable to an XSS attack.
In Rails 3, all input is escaped by default, taking the burden off of the developer of having to remember to escape everywhere that malicious code might be present. For those times that you do want to allow unescaped data to appear in your view, you can use the raw method to tell Rails 3 not to escape the data.

<%= raw @comment.text %>

==='''New Query Engine'''===
Rails 3 includes a cool new query engine that makes it easier to get back the data you want and gives you more flexibility in your controller code. These changes show up in various places, but the most common case is fetching data in your controller. In Rails 2, you could use the find method to retrieve the data you were looking for, passing in arguments to specify conditions, grouping, limits, and any other query information. For example:

@posts = Post.find(:all, :conditions => [ "category IN (?)", categories], :limit => 10, :order => "created_on DESC")

finds the first ten posts within some specified categories ordered by the creation time.

In Rails 3, each of the passed in parameters has its own method, which can be chained together to get the same results.

@posts = Post.where([ "category IN (?)", categories]).order("created_on DESC").limit(10)

The query is not actually executed until the data is needed; so these methods can even be used across multiple statements.

@posts = Post.where([ "category IN (?)", categories])
if(condition_a)
@posts = @posts.where(['approved=?', true])
else
@posts = @posts.where(['approved=?', false])
End

This is only a simple example, but should provide you with an idea of some of the ways this new syntax can be more useful.

==='''Easier Email'''===
The ActionMailer module has been rewritten to make it a lot easier for your application to send email in Rails 3.

'''1-Default Setting'''
In Rails, a Mailer is a class that can have many methods, each of which generally configure and send an email. Previously, you had to set all of the parameters for each email separately in each method.

class UserMailer < ActionMailer::Base
def welcome_email(user)
from "system@example.com" # other paramters
end
def password_reset(user)
from "system@example.com"
# other parameters
end
end

In Rails 3, you can specify defaults that can be optionally overwritten in each method.

class UserMailer < ActionMailer::Base
default :from => 'no-reply@example.com',
:return_path => 'system@example.com'

def welcome_email(user)
# no need to specify from parameter
end
end

'''2-Cleaner API'''
Previous versions of Rails required you to send email using special methods that were dynamically created by ActionMailer. For instance, if you wanted to deliver the welcome email in the example above, you would need to call:

UserMailer.deliver_welcome_email(@user)

ln Rails 3, you can just call

UserMailer.welcome_email(@user).deliver 

This makes more sense semantically, and additionally allows you to retrieve and manipulate the Mail object before delivering the email.

==='''Dependency Management'''===
One of the strengths of the Ruby on Rails framework is the plethora of gems available for use by developers. Whether it's authentication[https://github.com/binarylogic/authlogic],
handling financial[http://activemerchant.org/] transactions[https://github.com/thoughtbot/paperclip], handling file uploads, or nearly anything else, chances are a gem exists to help with your problem.

Issues can arise, however, if your gems require other gems, or developers are on different environments, among other things. To help solve these types of
situations, Rails 3 adds the Bundler[http://gembundler.com/] gem to help manage your dependencies. Using Bundler in Rails 3 is extremely simple; add a line for each gem you
require in your Gemfile, a file included in the root of each of your applications.

gem 'authlogic'
Once you've included all your gems, run:

bundle install

and Bundler will download and configure all of the gems and their dependencies that you need for the project.
Bundler also allows you to specify certain gems to only be configured in certain environments (development vs production vs testing).
These are only a few of the many changes included in Ruby on Rails 3. Many of the old APIs still work in Rails, even if they've been deprecated, to make it easier to update.

==='''ActiveRecord finder methods'''===
In Rails 2

User.find(:all, : order => "created_at desc", :limit => 5) 

Rails 3 looks at the hash of options that is being passed to find(:all, : order, and :limit) and replace each item in the hash with an equivalent method.
Rails 3 has a new API for the dynamic fiders

where, having, select, group, order, limit, offset, joins, includes, ...

So, in Rails 3 it becomes

User.order("created_at desc").limit(5)

==='''Active Record Validations'''===
There sre separate validations in Rails 2

validates_presence_of :username

validates_uniqueness_of :username

validates_length_of :email, :maximum => 40 

In Rails 3 these can be clubbed together

validates :email, :presence => true,

:uniqueness => true,

:length => {:maximum => 30}

==References==
[http://guides.rubyonrails.org/3_0_release_notes.html Rails 3 Documentation]

[http://guides.rubyonrails.org/2_3_release_notes.html Rails 2 Documentation]

[http://api.rubyonrails.org/ Rails API]

[http://guides.rubyonrails.org/3_0_release_notes.html#mail-extraction Rails Mailer]

CSC/ECE 517 Fall 2012/ch1 1w19 sa

2012-09-15T00:28:43Z

Sbhatta9:

==Introduction==
'''Rails''' is a MVC (Model-View-Controller) based architecture for web development based on the Ruby language. Rails 2[http://guides.rubyonrails.org/2_3_release_notes.html] was released in December 2007. Initially Rails 2 supported Ruby 1.8[http://www.ruby-lang.org/en/news/2008/05/31/ruby-1-8-7-has-been-released/]. It now has been updated to support Ruby 1.9.1[http://www.ruby-lang.org/en/news/2009/01/30/ruby-1-9-1-released/]. Rails 3 which brings in many improvements over Rails 2 supports Ruby 1.9 and above. The current stable version of Rails is 3.2.8[http://rubyonrails.org/download] released on Aug 9, 2012.
This wikibook chapter focuses mainly on the differences of Rails 2 and Rails 3.

==Differences between Rails 2 and Rails 3==
==='''Unobtrusive Javascript'''[http://en.wikipedia.org/wiki/Unobtrusive_JavaScript]===
In previous versions of Rails, JavaScript was generated inline with HTML, causing ugly and somewhat brittle code.
As an example, Rails allows you to use its link_to method to generate a delete link for some object.

<%= link_to "Delete this Post", @post, :confirm => "Do you really want to delete this post?", :method => :delete %>

Using this method in your view would generate the following in Rails 2:
<a href="/posts/6" onclick="if (confirm('Do you really want to delete this post?')) { var f = document.createElement('form');
f.style.display = 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action = this.href;
var m = document.createElement('input'); m.setAttribute('type', 'hidden'); m.setAttribute('name', '_method');
m.setAttribute('value', 'delete'); f.appendChild(m);f.submit(); };return false;">Delete this Post</a>

Rails 3 would generate something much simpler:

<a href='/posts/6"' rel="nofollow" data-method="delete" data-confirm="Do you really want to delete this post?">Delete this Post</a>

Rails 3 replaces all of the inline JavaScript with a couple of HTML5 attributes. All of the JavaScript event handlers to handle the actual confirmation box and deletion are stored in one central JavaScript file that is included with every rails project.

==='''No more dependency on only Prototype Javascript library'''===
One big advantage to this new method is that the JavaScript helpers are framework agnostic. Instead of being tied to the Prototype library like you were in Rails 2, you can now choose whatever JavaScript framework you like (Rails apps come with Prototype by default, but jQuery is now officially supported[https://github.com/rails/jquery-ujs].

==='''Improved Security'''===
Another awesome new feature of Rails 3 is that XSS[http://en.wikipedia.org/wiki/Cross-site_scripting] protection is now enabled by default. Rails 2 supported XSS protection through the use of the h method.
<%= h @comment.text %>
The h method would escape html and JavaScript to ensure that no malicious client-side code was executed. This method worked great, but there was one problem: you had to actually remember to use the h method everywhere the user entered input was displayed. If you forgot even one place, then you were vulnerable to an XSS attack.
In Rails 3, all input is escaped by default, taking the burden off of the developer of having to remember to escape everywhere that malicious code might be present. For those times that you do want to allow unescaped data to appear in your view, you can use the raw method to tell Rails 3 not to escape the data.

<%= raw @comment.text %>

==='''New Query Engine'''===
Rails 3 includes a cool new query engine that makes it easier to get back the data you want and gives you more flexibility in your controller code. These changes show up in various places, but the most common case is fetching data in your controller. In Rails 2, you could use the find method to retrieve the data you were looking for, passing in arguments to specify conditions, grouping, limits, and any other query information. For example:

@posts = Post.find(:all, :conditions => [ "category IN (?)", categories], :limit => 10, :order => "created_on DESC")

finds the first ten posts within some specified categories ordered by the creation time.

In Rails 3, each of the passed in parameters has its own method, which can be chained together to get the same results.

@posts = Post.where([ "category IN (?)", categories]).order("created_on DESC").limit(10)

The query is not actually executed until the data is needed; so these methods can even be used across multiple statements.

@posts = Post.where([ "category IN (?)", categories])
if(condition_a)
@posts = @posts.where(['approved=?', true])
else
@posts = @posts.where(['approved=?', false])
End

This is only a simple example, but should provide you with an idea of some of the ways this new syntax can be more useful.

==='''Easier Email'''===
The ActionMailer module has been rewritten to make it a lot easier for your application to send email in Rails 3.

'''1-Default Setting'''
In Rails, a Mailer is a class that can have many methods, each of which generally configure and send an email. Previously, you had to set all of the parameters for each email separately in each method.

class UserMailer < ActionMailer::Base
def welcome_email(user)
from "system@example.com" # other paramters
end
def password_reset(user)
from "system@example.com"
# other parameters
end
end

In Rails 3, you can specify defaults that can be optionally overwritten in each method.

class UserMailer < ActionMailer::Base
default :from => 'no-reply@example.com',
:return_path => 'system@example.com'

def welcome_email(user)
# no need to specify from parameter
end
end

'''2-Cleaner API'''
Previous versions of Rails required you to send email using special methods that were dynamically created by ActionMailer. For instance, if you wanted to deliver the welcome email in the example above, you would need to call:

UserMailer.deliver_welcome_email(@user)

ln Rails 3, you can just call

UserMailer.welcome_email(@user).deliver 

This makes more sense semantically, and additionally allows you to retrieve and manipulate the Mail object before delivering the email.

==='''Dependency Management'''===
One of the strengths of the Ruby on Rails framework is the plethora of gems available for use by developers. Whether it's authentication[https://github.com/binarylogic/authlogic],
handling financial[http://activemerchant.org/] transactions[https://github.com/thoughtbot/paperclip], handling file uploads, or nearly anything else, chances are a gem exists to help with your problem.

Issues can arise, however, if your gems require other gems, or developers are on different environments, among other things. To help solve these types of
situations, Rails 3 adds the Bundler[http://gembundler.com/] gem to help manage your dependencies. Using Bundler in Rails 3 is extremely simple; add a line for each gem you
require in your Gemfile, a file included in the root of each of your applications.

gem 'authlogic'
Once you've included all your gems, run:

bundle install

and Bundler will download and configure all of the gems and their dependencies that you need for the project.
Bundler also allows you to specify certain gems to only be configured in certain environments (development vs production vs testing).
These are only a few of the many changes included in Ruby on Rails 3. Many of the old APIs still work in Rails, even if they've been deprecated, to make it easier to update.

==='''ActiveRecord finder methods'''===
In Rails 2

User.find(:all, : order => "created_at desc", :limit => 5) 

Rails 3 looks at the hash of options that is being passed to find(:all, : order, and :limit) and replace each item in the hash with an equivalent method.
Rails 3 has a new API for the dynamic fiders

where, having, select, group, order, limit, offset, joins, includes, ...

So, in Rails 3 it becomes

User.order("created_at desc").limit(5)

==='''Active Record Validations'''===
There sre separate validations in Rails 2

validates_presence_of :username

validates_uniqueness_of :username

validates_length_of :email, :maximum => 40 

In Rails 3 these can be clubbed together

validates :email, :presence => true,

:uniqueness => true,

:length => {:maximum => 30}

==References==
[http://guides.rubyonrails.org/3_0_release_notes.html Rails 3 Documentation]

[http://guides.rubyonrails.org/2_3_release_notes.html]

[http://api.rubyonrails.org/]

[http://guides.rubyonrails.org/3_0_release_notes.html#mail-extraction]

[http://lindsaar.net/2010/1/26/new-actionmailer-api-in-rails-3]

CSC/ECE 517 Fall 2012/ch1 1w19 sa

2012-09-15T00:26:01Z

Sbhatta9:

==Introduction==
'''Rails''' is a MVC (Model-View-Controller) based architecture for web development based on the Ruby language. Rails 2[http://guides.rubyonrails.org/2_3_release_notes.html] was released in December 2007. Initially Rails 2 supported Ruby 1.8[http://www.ruby-lang.org/en/news/2008/05/31/ruby-1-8-7-has-been-released/]. It now has been updated to support Ruby 1.9.1[http://www.ruby-lang.org/en/news/2009/01/30/ruby-1-9-1-released/]. Rails 3 which brings in many improvements over Rails 2 supports Ruby 1.9 and above. The current stable version of Rails is 3.2.8[http://rubyonrails.org/download] released on Aug 9, 2012.
This wikibook chapter focuses mainly on the differences of Rails 2 and Rails 3.

==Differences between Rails 2 and Rails 3==
==='''Unobtrusive Javascript'''[http://en.wikipedia.org/wiki/Unobtrusive_JavaScript]===
In previous versions of Rails, JavaScript was generated inline with HTML, causing ugly and somewhat brittle code.
As an example, Rails allows you to use its link_to method to generate a delete link for some object.

<%= link_to "Delete this Post", @post, :confirm => "Do you really want to delete this post?", :method => :delete %>

Using this method in your view would generate the following in Rails 2:
<a href="/posts/6" onclick="if (confirm('Do you really want to delete this post?')) { var f = document.createElement('form');
f.style.display = 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action = this.href;
var m = document.createElement('input'); m.setAttribute('type', 'hidden'); m.setAttribute('name', '_method');
m.setAttribute('value', 'delete'); f.appendChild(m);f.submit(); };return false;">Delete this Post</a>

Rails 3 would generate something much simpler:

<a href='/posts/6"' rel="nofollow" data-method="delete" data-confirm="Do you really want to delete this post?">Delete this Post</a>

Rails 3 replaces all of the inline JavaScript with a couple of HTML5 attributes. All of the JavaScript event handlers to handle the actual confirmation box and deletion are stored in one central JavaScript file that is included with every rails project.

==='''No more dependency on only Prototype Javascript library'''===
One big advantage to this new method is that the JavaScript helpers are framework agnostic. Instead of being tied to the Prototype library like you were in Rails 2, you can now choose whatever JavaScript framework you like (Rails apps come with Prototype by default, but jQuery is now officially supported[https://github.com/rails/jquery-ujs].

==='''Improved Security'''===
Another awesome new feature of Rails 3 is that XSS[http://en.wikipedia.org/wiki/Cross-site_scripting] protection is now enabled by default. Rails 2 supported XSS protection through the use of the h method.
<%= h @comment.text %>
The h method would escape html and JavaScript to ensure that no malicious client-side code was executed. This method worked great, but there was one problem: you had to actually remember to use the h method everywhere the user entered input was displayed. If you forgot even one place, then you were vulnerable to an XSS attack.
In Rails 3, all input is escaped by default, taking the burden off of the developer of having to remember to escape everywhere that malicious code might be present. For those times that you do want to allow unescaped data to appear in your view, you can use the raw method to tell Rails 3 not to escape the data.

<%= raw @comment.text %>

==='''New Query Engine'''===
Rails 3 includes a cool new query engine that makes it easier to get back the data you want and gives you more flexibility in your controller code. These changes show up in various places, but the most common case is fetching data in your controller. In Rails 2, you could use the find method to retrieve the data you were looking for, passing in arguments to specify conditions, grouping, limits, and any other query information. For example:

@posts = Post.find(:all, :conditions => [ "category IN (?)", categories], :limit => 10, :order => "created_on DESC")

finds the first ten posts within some specified categories ordered by the creation time.

In Rails 3, each of the passed in parameters has its own method, which can be chained together to get the same results.

@posts = Post.where([ "category IN (?)", categories]).order("created_on DESC").limit(10)

The query is not actually executed until the data is needed; so these methods can even be used across multiple statements.

@posts = Post.where([ "category IN (?)", categories])
if(condition_a)
@posts = @posts.where(['approved=?', true])
else
@posts = @posts.where(['approved=?', false])
End

This is only a simple example, but should provide you with an idea of some of the ways this new syntax can be more useful.

==='''Easier Email'''===
The ActionMailer module has been rewritten to make it a lot easier for your application to send email in Rails 3.

'''1-Default Setting'''
In Rails, a Mailer is a class that can have many methods, each of which generally configure and send an email. Previously, you had to set all of the parameters for each email separately in each method.

class UserMailer < ActionMailer::Base
def welcome_email(user)
from "system@example.com" # other paramters
end
def password_reset(user)
from "system@example.com"
# other parameters
end
end

In Rails 3, you can specify defaults that can be optionally overwritten in each method.

class UserMailer < ActionMailer::Base
default :from => 'no-reply@example.com',
:return_path => 'system@example.com'

def welcome_email(user)
# no need to specify from parameter
end
end

'''2-Cleaner API'''
Previous versions of Rails required you to send email using special methods that were dynamically created by ActionMailer. For instance, if you wanted to deliver the welcome email in the example above, you would need to call:

UserMailer.deliver_welcome_email(@user)

ln Rails 3, you can just call

UserMailer.welcome_email(@user).deliver 

This makes more sense semantically, and additionally allows you to retrieve and manipulate the Mail object before delivering the email.

==='''Dependency Management'''===
One of the strengths of the Ruby on Rails framework is the plethora of gems available for use by developers. Whether it's authentication[https://github.com/binarylogic/authlogic],
handling financial[http://activemerchant.org/] transactions[https://github.com/thoughtbot/paperclip], handling file uploads, or nearly anything else, chances are a gem exists to help with your problem.

Issues can arise, however, if your gems require other gems, or developers are on different environments, among other things. To help solve these types of
situations, Rails 3 adds the Bundler[http://gembundler.com/] gem to help manage your dependencies. Using Bundler in Rails 3 is extremely simple; add a line for each gem you
require in your Gemfile, a file included in the root of each of your applications.

gem 'authlogic'
Once you've included all your gems, run:

bundle install

and Bundler will download and configure all of the gems and their dependencies that you need for the project.
Bundler also allows you to specify certain gems to only be configured in certain environments (development vs production vs testing).
These are only a few of the many changes included in Ruby on Rails 3. Many of the old APIs still work in Rails, even if they've been deprecated, to make it easier to update.

==='''ActiveRecord finder methods'''===
In Rails 2

User.find(:all, : order => "created_at desc", :limit => 5) 

Rails 3 looks at the hash of options that is being passed to find(:all, : order, and :limit) and replace each item in the hash with an equivalent method.
Rails 3 has a new API for the dynamic fiders

where, having, select, group, order, limit, offset, joins, includes, ...

So, in Rails 3 it becomes

User.order("created_at desc").limit(5)

==='''Active Record Validations'''===
There sre separate validations in Rails 2

validates_presence_of :username

validates_uniqueness_of :username

validates_length_of :email, :maximum => 40 

In Rails 3 these can be clubbed together

validates :email, :presence => true,

:uniqueness => true,

:length => {:maximum => 30}

==References==
[http://guides.rubyonrails.org/3_0_release_notes.html]

[http://guides.rubyonrails.org/2_3_release_notes.html]

[http://api.rubyonrails.org/]

[http://guides.rubyonrails.org/3_0_release_notes.html#mail-extraction]

[http://lindsaar.net/2010/1/26/new-actionmailer-api-in-rails-3]

CSC/ECE 517 Fall 2012/ch1 1w19 sa

2012-09-15T00:20:27Z

Sbhatta9:

==Introduction==
'''Rails''' is a MVC (Model-View-Controller) based architecture for web development based on the Ruby language. Rails 2[http://guides.rubyonrails.org/2_3_release_notes.html] was released in December 2007. Initially Rails 2 supported Ruby 1.8[http://www.ruby-lang.org/en/news/2008/05/31/ruby-1-8-7-has-been-released/]. It now has been updated to support Ruby 1.9.1[http://www.ruby-lang.org/en/news/2009/01/30/ruby-1-9-1-released/]. Rails 3 which brings in many improvements over Rails 2 supports Ruby 1.9 and above. The current stable version of Rails is 3.2.8[http://rubyonrails.org/download] released on Aug 9, 2012.
This wikibook chapter focuses mainly on the differences of Rails 2 and Rails 3.

==Differences between Rails 2 and Rails 3==
==='''Unobtrusive Javascript'''[http://en.wikipedia.org/wiki/Unobtrusive_JavaScript]===
In previous versions of Rails, JavaScript was generated inline with HTML, causing ugly and somewhat brittle code.
As an example, Rails allows you to use its link_to method to generate a delete link for some object.

<%= link_to "Delete this Post", @post, :confirm => "Do you really want to delete this post?", :method => :delete %>

Using this method in your view would generate the following in Rails 2:
<a href="/posts/6" onclick="if (confirm('Do you really want to delete this post?')) { var f = document.createElement('form');
f.style.display = 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action = this.href;
var m = document.createElement('input'); m.setAttribute('type', 'hidden'); m.setAttribute('name', '_method');
m.setAttribute('value', 'delete'); f.appendChild(m);f.submit(); };return false;">Delete this Post</a>

Rails 3 would generate something much simpler:

<a href='/posts/6"' rel="nofollow" data-method="delete" data-confirm="Do you really want to delete this post?">Delete this Post</a>

Rails 3 replaces all of the inline JavaScript with a couple of HTML5 attributes. All of the JavaScript event handlers to handle the actual confirmation box and deletion are stored in one central JavaScript file that is included with every rails project.

==='''No more dependency on only Prototype Javascript library'''===
One big advantage to this new method is that the JavaScript helpers are framework agnostic. Instead of being tied to the Prototype library like you were in Rails 2, you can now choose whatever JavaScript framework you like (Rails apps come with Prototype by default, but jQuery is now officially supported[https://github.com/rails/jquery-ujs].

==='''Improved Security'''===
Another awesome new feature of Rails 3 is that XSS[http://en.wikipedia.org/wiki/Cross-site_scripting] protection is now enabled by default. Rails 2 supported XSS protection through the use of the h method.
<%= h @comment.text %>
The h method would escape html and JavaScript to ensure that no malicious client-side code was executed. This method worked great, but there was one problem: you had to actually remember to use the h method everywhere the user entered input was displayed. If you forgot even one place, then you were vulnerable to an XSS attack.
In Rails 3, all input is escaped by default, taking the burden off of the developer of having to remember to escape everywhere that malicious code might be present. For those times that you do want to allow unescaped data to appear in your view, you can use the raw method to tell Rails 3 not to escape the data.

<%= raw @comment.text %>

==='''New Query Engine'''===
Rails 3 includes a cool new query engine that makes it easier to get back the data you want and gives you more flexibility in your controller code. These changes show up in various places, but the most common case is fetching data in your controller. In Rails 2, you could use the find method to retrieve the data you were looking for, passing in arguments to specify conditions, grouping, limits, and any other query information. For example:

@posts = Post.find(:all, :conditions => [ "category IN (?)", categories], :limit => 10, :order => "created_on DESC")

finds the first ten posts within some specified categories ordered by the creation time.

In Rails 3, each of the passed in parameters has its own method, which can be chained together to get the same results.

@posts = Post.where([ "category IN (?)", categories]).order("created_on DESC").limit(10)

The query is not actually executed until the data is needed; so these methods can even be used across multiple statements.

@posts = Post.where([ "category IN (?)", categories])
if(condition_a)
@posts = @posts.where(['approved=?', true])
else
@posts = @posts.where(['approved=?', false])
End

This is only a simple example, but should provide you with an idea of some of the ways this new syntax can be more useful.

==='''Easier Email'''===
The ActionMailer module has been rewritten to make it a lot easier for your application to send email in Rails 3.

'''1-Default Setting'''
In Rails, a Mailer is a class that can have many methods, each of which generally configure and send an email. Previously, you had to set all of the parameters for each email separately in each method.

class UserMailer < ActionMailer::Base
def welcome_email(user)
from "system@example.com" # other paramters
end
def password_reset(user)
from "system@example.com"
# other parameters
end
end

In Rails 3, you can specify defaults that can be optionally overwritten in each method.

class UserMailer < ActionMailer::Base
default :from => 'no-reply@example.com',
:return_path => 'system@example.com'

def welcome_email(user)
# no need to specify from parameter
end
end

'''2-Cleaner API'''
Previous versions of Rails required you to send email using special methods that were dynamically created by ActionMailer. For instance, if you wanted to deliver the welcome email in the example above, you would need to call:

UserMailer.deliver_welcome_email(@user)

ln Rails 3, you can just call

UserMailer.welcome_email(@user).deliver 

This makes more sense semantically, and additionally allows you to retrieve and manipulate the Mail object before delivering the email.

==='''Dependency Management'''===
One of the strengths of the Ruby on Rails framework is the plethora of gems available for use by developers. Whether it's authentication[https://github.com/binarylogic/authlogic],
handling financial[http://activemerchant.org/] transactions[https://github.com/thoughtbot/paperclip], handling file uploads, or nearly anything else, chances are a gem exists to help with your problem.

Issues can arise, however, if your gems require other gems, or developers are on different environments, among other things. To help solve these types of
situations, Rails 3 adds the Bundler[http://gembundler.com/] gem to help manage your dependencies. Using Bundler in Rails 3 is extremely simple; add a line for each gem you
require in your Gemfile, a file included in the root of each of your applications.

gem 'authlogic'
Once you've included all your gems, run:

bundle install

and Bundler will download and configure all of the gems and their dependencies that you need for the project.
Bundler also allows you to specify certain gems to only be configured in certain environments (development vs production vs testing).
These are only a few of the many changes included in Ruby on Rails 3. Many of the old APIs still work in Rails, even if they've been deprecated, to make it easier to update.

==='''ActiveRecord finder methods'''===
In Rails 2

User.find(:all, : order => "created_at desc", :limit => 5) 

Rails 3 looks at the hash of options that is being passed to find(:all, : order, and :limit) and replace each item in the hash with an equivalent method.
Rails 3 has a new API for the dynamic fiders

where, having, select, group, order, limit, offset, joins, includes, ...

So, in Rails 3 it becomes

User.order("created_at desc").limit(5)

==='''Active Record Validations'''===
There sre separate validations in Rails 2

validates_presence_of :username

validates_uniqueness_of :username

validates_length_of :email, :maximum => 40 

In Rails 3 these can be clubbed together

validates :email, :presence => true,

:uniqueness => true,

:length => {:maximum => 30}

==References==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w19 sa

2012-09-15T00:11:33Z

Sbhatta9:

==Introduction==
'''Rails''' is a MVC (Model-View-Controller) based architecture for web development based on the Ruby language. Rails 2[http://guides.rubyonrails.org/2_3_release_notes.html] was released in December 2007. Initially Rails 2 supported Ruby 1.8[http://www.ruby-lang.org/en/news/2008/05/31/ruby-1-8-7-has-been-released/]. It now has been updated to support Ruby 1.9.1[http://www.ruby-lang.org/en/news/2009/01/30/ruby-1-9-1-released/]. Rails 3 which brings in many improvements over Rails 2 supports Ruby 1.9 and above. The current stable version of Rails is 3.2.8[http://rubyonrails.org/download] released on Aug 9, 2012.
This wikibook chapter focuses mainly on the differences of Rails 2 and Rails 3.

==Differences between Rails 2 and Rails 3==
==='''Unobtrusive Javascript'''[http://en.wikipedia.org/wiki/Unobtrusive_JavaScript]===
In previous versions of Rails, JavaScript was generated inline with HTML, causing ugly and somewhat brittle code.
As an example, Rails allows you to use its link_to method to generate a delete link for some object.

<%= link_to "Delete this Post", @post, :confirm => "Do you really want to delete this post?", :method => :delete %>

Using this method in your view would generate the following in Rails 2:
<a href="/posts/6" onclick="if (confirm('Do you really want to delete this post?')) { var f = document.createElement('form');
f.style.display = 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action = this.href;
var m = document.createElement('input'); m.setAttribute('type', 'hidden'); m.setAttribute('name', '_method');
m.setAttribute('value', 'delete'); f.appendChild(m);f.submit(); };return false;">Delete this Post</a>

Rails 3 would generate something much simpler:

<a href='/posts/6"' rel="nofollow" data-method="delete" data-confirm="Do you really want to delete this post?">Delete this Post</a>

Rails 3 replaces all of the inline JavaScript with a couple of HTML5 attributes. All of the JavaScript event handlers to handle the actual confirmation box and deletion are stored in one central JavaScript file that is included with every rails project.

==='''No more dependency on only Prototype Javascript library'''===
One big advantage to this new method is that the JavaScript helpers are framework agnostic. Instead of being tied to the Prototype library like you were in Rails 2, you can now choose whatever JavaScript framework you like (Rails apps come with Prototype by default, but jQuery is now officially supported[https://github.com/rails/jquery-ujs].

==='''Improved Security'''===
Another awesome new feature of Rails 3 is that XSS[http://en.wikipedia.org/wiki/Cross-site_scripting] protection is now enabled by default. Rails 2 supported XSS protection through the use of the h method.
<%= h @comment.text %>
The h method would escape html and JavaScript to ensure that no malicious client-side code was executed. This method worked great, but there was one problem: you had to actually remember to use the h method everywhere the user entered input was displayed. If you forgot even one place, then you were vulnerable to an XSS attack.
In Rails 3, all input is escaped by default, taking the burden off of the developer of having to remember to escape everywhere that malicious code might be present. For those times that you do want to allow unescaped data to appear in your view, you can use the raw method to tell Rails 3 not to escape the data.

<%= raw @comment.text %>

==='''New Query Engine'''===
Rails 3 includes a cool new query engine that makes it easier to get back the data you want and gives you more flexibility in your controller code. These changes show up in various places, but the most common case is fetching data in your controller. In Rails 2, you could use the find method to retrieve the data you were looking for, passing in arguments to specify conditions, grouping, limits, and any other query information. For example:

@posts = Post.find(:all, :conditions => [ "category IN (?)", categories], :limit => 10, :order => "created_on DESC")

finds the first ten posts within some specified categories ordered by the creation time.

In Rails 3, each of the passed in parameters has its own method, which can be chained together to get the same results.

@posts = Post.where([ "category IN (?)", categories]).order("created_on DESC").limit(10)

The query is not actually executed until the data is needed; so these methods can even be used across multiple statements.

@posts = Post.where([ "category IN (?)", categories])
if(condition_a)
@posts = @posts.where(['approved=?', true])
else
@posts = @posts.where(['approved=?', false])
End

This is only a simple example, but should provide you with an idea of some of the ways this new syntax can be more useful.

==='''Easier Email'''===
The ActionMailer module has been rewritten to make it a lot easier for your application to send email in Rails 3.

'''1-Default Setting'''
In Rails, a Mailer is a class that can have many methods, each of which generally configure and send an email. Previously, you had to set all of the parameters for each email separately in each method.

class UserMailer < ActionMailer::Base
def welcome_email(user)
from "system@example.com" # other paramters
end
def password_reset(user)
from "system@example.com"
# other parameters
end
end

In Rails 3, you can specify defaults that can be optionally overwritten in each method.

class UserMailer < ActionMailer::Base
default :from => 'no-reply@example.com',
:return_path => 'system@example.com'

def welcome_email(user)
# no need to specify from parameter
end
end

'''2-Cleaner API'''
Previous versions of Rails required you to send email using special methods that were dynamically created by ActionMailer. For instance, if you wanted to deliver the welcome email in the example above, you would need to call:

UserMailer.deliver_welcome_email(@user)

ln Rails 3, you can just call

UserMailer.welcome_email(@user).deliver 

This makes more sense semantically, and additionally allows you to retrieve and manipulate the Mail object before delivering the email.

==='''Dependency Management'''===
One of the strengths of the Ruby on Rails framework is the plethora of gems available for use by developers. Whether it's authentication[https://github.com/binarylogic/authlogic],
handling financial[http://activemerchant.org/] transactions[https://github.com/thoughtbot/paperclip], handling file uploads, or nearly anything else, chances are a gem exists to help with your problem.

Issues can arise, however, if your gems require other gems, or developers are on different environments, among other things. To help solve these types of
situations, Rails 3 adds the Bundler[http://gembundler.com/] gem to help manage your dependencies. Using Bundler in Rails 3 is extremely simple; add a line for each gem you
require in your Gemfile, a file included in the root of each of your applications.

gem 'authlogic'
Once you've included all your gems, run:

bundle install

and Bundler will download and configure all of the gems and their dependencies that you need for the project.
Bundler also allows you to specify certain gems to only be configured in certain environments (development vs production vs testing).
These are only a few of the many changes included in Ruby on Rails 3. Many of the old APIs still work in Rails, even if they've been deprecated, to make it easier to update.

==='''ActiveRecord finder methods'''===
In Rails 2

User.find(:all, : order => "created_at desc", :limit => 5) 

Rails 3 looks at the hash of options that is being passed to find(:all, : order, and :limit) and replace each item in the hash with an equivalent method.
Rails 3 has a new API for the dynamic fiders

where, having, select, group, order, limit, offset, joins, includes, ...

So, in Rails 3 it becomes

User.order("created_at desc").limit(5)

==='''Active Record Validations'''===
There sre separate validations in Rails 2

validates_presence_of :username

validates_uniqueness_of :username

validates_length_of :email, :maximum => 40 

In Rails 3 these can be clubbed together

validates :email, :presence => true,

:uniqueness => true,

:length => {:maximum => 30}

CSC/ECE 517 Fall 2012

2012-09-14T20:01:07Z

Sbhatta9:

*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]

CSC/ECE 517 Fall 2012

2012-09-14T19:59:05Z

Sbhatta9: