Expertiza_Wiki - User contributions [en]

Using heroku to deploy your projects

2011-10-06T01:15:33Z

Gstungat: /* What do I need? */

= Heroku for deploying projects =
== What is Heroku? ==
Heroku is a cloud application platform (or a PaaS) that allows developers to easily deploy their apps without worrying about servers, hosting, etc.
 
We are going to use heroku to deploy the backchannel app of project 1. There are several advantages:
# You have a deployed app ready to test in under 5 minutes
# You have a public URL that you can show off to potential interviewers :)
# Basic signup is free!

== What do I need? ==
* Go to [http://www.heroku.com Heroku] and sign up for an account. It is free to sign up.
* Develop and run your app locally
* Install git and use it to track your application. More about how to do that [[Using_git_and_github_for_projects]]
* Create a public SSH key
$ ssh-keygen -t rsa -C "your_email@youremail.com"
* Install the heroku gem
gem install heroku
heroku keys:add
You will have to enter your heroku credentials
* Create your heroku application.
In your project directory,
heroku create
* Push to heroku
git push heroku master
* Migrate your database
heroku rake db:migrate
Viola you are done! Your public URL is specified when you did heroku create. Your application is all set to go!
 

== Heroku help ==
This guide has been taken largely from the heroku dev center. Look at [http://devcenter.heroku.com/articles/quickstart Heroku HowTo] for more details. Also, effectively use google to solve your doubts, there is plenty of help available.

Using heroku to deploy your projects

2011-10-05T17:05:25Z

Gstungat: /* What do I need? */

= Heroku for deploying projects =
== What is Heroku? ==
Heroku is a cloud application platform (or a PaaS) that allows developers to easily deploy their apps without worrying about servers, hosting, etc.
 
We are going to use heroku to deploy the backchannel app of project 1. There are several advantages:
# You have a deployed app ready to test in under 5 minutes
# You have a public URL that you can show off to potential interviewers :)
# Basic signup is free!

== What do I need? ==
* Go to [http://www.heroku.com Heroku] and sign up for an account. It is free to sign up.
* Develop and run your app locally
* Install git and use it to track your application. More about how to do that [[Using_git_and_github_for_projects]]
* Create a public SSH key
$ ssh-keygen -t rsa -C "your_email@youremail.com"
* Install the heroku gem
gem install heroku
heroku keys:add
You will have to enter your heroku credentials
* Create your heroku application.
In your project directory,
heroku create
* Push to heroku
git push heroku master
* Migrate your database
heroku rake db:create
Viola you are done! Your public URL is specified when you did heroku create. Your application is all set to go!
 

== Heroku help ==
This guide has been taken largely from the heroku dev center. Look at [http://devcenter.heroku.com/articles/quickstart Heroku HowTo] for more details. Also, effectively use google to solve your doubts, there is plenty of help available.

Using heroku to deploy your projects

2011-10-05T01:45:04Z

Gstungat:

= Heroku for deploying projects =
== What is Heroku ==
Heroku is a cloud application platform (or a PaaS) that allows developers to easily deploy their apps without worrying about servers, hosting, etc.
 
We are going to use heroku to deploy the backchannel app of project 1. There are several advantages:
# You have a deployed app ready to test in under 5 minutes
# You have a public URL that you can show off to potential interviewers :)
# Basic signup is free!

== What do I need ==
* Go to [http://www.heroku.com Heroku] and sign up for an account. It is free to sign up.
* Develop and run your app locally
* Install git and use it to track your application. More about how to do that [[Using_git_and_github_for_projects]]
* Create a public SSH key
$ ssh-keygen -t rsa -C "your_email@youremail.com"
* Install the heroku gem
gem install heroku
heroku keys:add
You will have to enter your heroku credentials
* Create your heroku application.
In your project directory,
heroku create
* Push to heroku
git push heroku master
* Migrate your database
heroku keys:add
Viola you are done! Your public URL is specified when you did heroku create. Your application is all set to go!
 
== Heroku help ==
This guide has been taken largely from the heroku dev center. Look at [http://devcenter.heroku.com/articles/quickstart Heroku HowTo] for more details. Also, effectively use google to solve your doubts, there is plenty of help available.

Using heroku to deploy your projects

2011-10-05T01:43:49Z

Gstungat: Created page with "= Heroku for deploying projects = == What is Heroku == Heroku is a cloud application platform (or a PaaS) that allows developers to easily deploy their apps without worrying abou..."

= Heroku for deploying projects =
== What is Heroku ==
Heroku is a cloud application platform (or a PaaS) that allows developers to easily deploy their apps without worrying about servers, hosting, etc.
 
We are going to use heroku to deploy the backchannel app of project 1. There are several advantages:
# You have a deployed app ready to test in under 5 minutes
# You have a public URL that you can show off to potential interviewers :)
# Basic signup is free!

== What do I need ==
# Go to [http://www.heroku.com Heroku] and sign up for an account. It is free to sign up.
# Develop and run your app locally
# Install git and use it to track your application. More about how to do that [[Using_git_and_github_for_projects]]
# Create a public SSH key
$ ssh-keygen -t rsa -C "your_email@youremail.com"
# Install the heroku gem
gem install heroku
heroku keys:add
You will have to enter your heroku credentials
# Create your heroku application.
In your project directory,
heroku create
# Push to heroku
git push heroku master
# Migrate your database
heroku keys:add
Viola you are done! Your public URL is specified when you did heroku create. Your application is all set to go!
 
== Heroku help ==
This guide has been taken largely from the heroku dev center. Look at [http://devcenter.heroku.com/articles/quickstart Heroku HowTo] for more details. Also, effectively use google to solve your doubts, there is plenty of help available.

MainPage

2011-10-05T00:56:43Z

Gstungat:

* [[ELI demo]]
* [[CSC 216]] learning exercise
* [[Expertiza documentation]]
* [[CSC 379]]
* [[CSC/ECE 506 Fall 2007]]
* [[ECE506_Main_Page | CSC/ECE 506 Main Portal]]
* [[CSC/ECE 517 Fall 2007]]
* [[CSC/ECE 517 Summer 2008]]
* [[CSC/ECE 517 Fall 2010]]
* [[CSC/ECE 517 Fall 2011]]
* [[Object-Oriented Design and Programming]]
* [[ECE 633]]
* [[KCU]]
* [[Progress reports]]
* [[Creating a Linux Development Environment for Expertiza - Installation Guide]]
* [[Using git and github for projects]]
* [[Using heroku to deploy your projects]]

File:Desert.jpg

2011-09-07T21:06:07Z

Gstungat:

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-12-12T22:35:54Z

Gstungat:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles.
<ol>
<li> SRP- The Single Responsibility Principle - A class should have one, and only one, reason to change.</li>
<li> OCP- The Open Closed Principle - You should be able to extend a classes behavior, without modifying it.</li>
<li> LSP- The Liskov Substitution Principle - Derived classes must be substitutable for their base classes.</li>
<li> DIP- The Dependency Inversion Principle- Depend on abstractions, not on concretions.</li>
<li> ISP- The Interface Segregation Principle- Make fine grained interfaces that are client specific.</li>
</ol>

In this chapter we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DON'T USE.[http://www.objectmentor.com/resources/articles/isp.pdf]</li>
</ul>
Good OO design is characterized by high cohesion and low coupling. This principle deals with high cohesion in designing interfaces.

==Implications of the emphasis==
<ol>
<li>This principle provides guidelines to write our interfaces. When we write interfaces we should avoid the temptation to bunch together several different methods in one interface. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.

</li>
</ol>

==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<li> [http://www.oodesign.com/interface-segregation-principle.html The Interface Segregation Principle]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-12-12T22:34:40Z

Gstungat:

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles.
<ol>
<li> SRP- The Single Responsibility Principle - A class should have one, and only one, reason to change.</li>
<li> OCP- The Open Closed Principle - You should be able to extend a classes behavior, without modifying it.</li>
<li> LSP- The Liskov Substitution Principle - Derived classes must be substitutable for their base classes.</li>
<li> DIP- The Dependency Inversion Principle- Depend on abstractions, not on concretions.</li>
<li> ISP- The Interface Segregation Principle- Make fine grained interfaces that are client specific.</li>
</ol>

In this chapter we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DON'T USE.[http://www.objectmentor.com/resources/articles/isp.pdf 1]</li>
</ul>
Good OO design is characterized by high cohesion and low coupling. This principle deals with high cohesion in designing interfaces.

==Implications of the emphasis==
<ol>
<li>This principle provides guidelines to write our interfaces. When we write interfaces we should avoid the temptation to bunch together several different methods in one interface. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.

</li>
</ol>

==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<li> [http://www.oodesign.com/interface-segregation-principle.html The Interface Segregation Principle]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-18T00:16:20Z

Gstungat: /* External References */

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles.
<ol>
<li> SRP- The Single Responsibility Principle - A class should have one, and only one, reason to change.</li>
<li> OCP- The Open Closed Principle - You should be able to extend a classes behavior, without modifying it.</li>
<li> LSP- The Liskov Substitution Principle - Derived classes must be substitutable for their base classes.</li>
<li> DIP- The Dependency Inversion Principle- Depend on abstractions, not on concretions.</li>
<li> ISP- The Interface Segregation Principle- Make fine grained interfaces that are client specific.</li>
</ol>

In this chapter we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DON'T USE.</li>
</ul>
Good OO design is characterized by high cohesion and low coupling. This principle deals with high cohesion in designing interfaces.

==Implications of the emphasis==
<ol>
<li>This principle provides guidelines to write our interfaces. When we write interfaces we should avoid the temptation to bunch together several different methods in one interface. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.

</li>
</ol>

==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<li> [http://www.oodesign.com/interface-segregation-principle.html The Interface Segregation Principle]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-18T00:13:40Z

Gstungat: /* Interface Segregation Principle */

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles.
<ol>
<li> SRP- The Single Responsibility Principle - A class should have one, and only one, reason to change.</li>
<li> OCP- The Open Closed Principle - You should be able to extend a classes behavior, without modifying it.</li>
<li> LSP- The Liskov Substitution Principle - Derived classes must be substitutable for their base classes.</li>
<li> DIP- The Dependency Inversion Principle- Depend on abstractions, not on concretions.</li>
<li> ISP- The Interface Segregation Principle- Make fine grained interfaces that are client specific.</li>
</ol>

In this chapter we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DON'T USE.</li>
</ul>
Good OO design is characterized by high cohesion and low coupling. This principle deals with high cohesion in designing interfaces.

==Implications of the emphasis==
<ol>
<li>This principle provides guidelines to write our interfaces. When we write interfaces we should avoid the temptation to bunch together several different methods in one interface. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.

</li>
</ol>

==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch6 6f ag

2010-11-18T00:07:50Z

Gstungat: /* Implications of the emphasis */

Interface Segregation Principle

==Introduction==
Design phase is a very important phase in the entire process of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle] object-oriented software development. The need for a good design of software is to accommodate change into the software, a definite attribute of any software. For the benefit of the developers of these software, certain principles are laid out which ensure that the outcome of development phase is an easily manageable software rather than a rigid and fragile software. The principles of object-oriented software development are listed differently in different sources. The most commonly accepted and recognized is the [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29]SOLID object oriented principles.
<ol>
<li> SRP- The Single Responsibility Principle - A class should have one, and only one, reason to change.</li>
<li> OCP- The Open Closed Principle - You should be able to extend a classes behavior, without modifying it.</li>
<li> LSP- The Liskov Substitution Principle - Derived classes must be substitutable for their base classes.</li>
<li> DIP- The Dependency Inversion Principle- Depend on abstractions, not on concretions.</li>
<li> ISP- The Interface Segregation Principle- Make fine grained interfaces that are client specific.</li>
</ol>

In this chapter we focus on Interface segregation principle (ISP).

==Interface Segregation Principle==
Interface Segregation Principle emphasizes on
<ul>
<li>MANY CLIENT SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL PURPOSE INTERFACE</li>
<li>CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DON'T USE.</li>
</ul>
==Implications of the emphasis==
<ol>
<li>This principle provides guidelines to write our interfaces. When we write interfaces we should avoid the temptation to bunch together several different methods in one interface. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
</li>
<li>The interfaces that are designed should not be fat, i.e the interface should not have too many methods which often do not get used together.
The idea here is to avoid loading all the methods into a single interface, instead segregate the methods in the interface such that all the methods that contribute towards offering a single type of service (or single type of clients) are grouped under one single interface. Thereby dealing with a bulky interface that might be difficult to manage is avoided.
</li>

<li>
The interface should be specific. The methods in the interface should be the ones that contribute towards offering only a specific type of service. For example, if there is an interface that offers methods that provide mathematical services to its clients, then the same interface should not contain methods that accomplish totally different types of tasks say, like a database functionality implementation.
The main reason behind such interfaces being discouraged is that if a class decides to (or has to) implement that interface, then, it has to provide an implementation even for those methods that it doesn’t intend to use. Even though such implementations may be empty methods, it is not convenient and also distorts the readability of the code.

</li>
</ol>

==Results of following ISP==
Designing software by adopting ISP will yield many simple interfaces that are more specific in nature which in turn will make the classes more cohesive.
==How ISP can be implemented in the design==
===Segregation through Delegation===
The object form of the ADAPTER Pattern can be used to delegate the responsibility of implementing the thin interface to the class that is the client of the interface.
===Segregation through multiple inheritance===
The methods that are to be included into the interfaces are grouped into interfaces such that all the methods in the interface are directed towards accomplishing a certain type of service. When a class has to use the methods in the interface, it has to implement the interface. When the class is required to implement methods from many interfaces, the class will have to inherit multiple light interfaces and also implement the methods in the interfaces.

==Example==
Consider an example of Course registration system which allows students to enroll in courses, similar to the one we have at NCSU.
Let us assume we have a student base class which other specialized student classes inherit from.

A full time student is allowed to register for a class. He can also choose to audit a particular class.

Lets say we have an interface called IEnroll.
The IEnroll interface exposes two methods viz. registerClass() which should allow a student to register himself for a class, and auditClass() which allows a student to audit a class he has registered for.
The FullStudent class is used to represent full time students. It extends the Student class and implements this IEnroll interface.
 
 
 
[[Image:Figure 1Class diagram for FullStudent (violates ISP).png]]
 
 
 
interface IEnroll {
public void registerClass();
public void auditClass();
}

class FullStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}

Now lets suppose, NCSU decided not to allow part time students to audit a class once they have registered.
The PartStudent class represents the part time students. It extends the Student class.
Now PartStudent class can either implement IEnroll to provide the registration facility. But in that case, PartStudent is forced to implement the auditClass method.
 
 
 
[[Image:Figure 2Class diagram for PartStudent (violates ISP).png ]]
 
 
 
class PartStudent extends Student implements IEnroll {
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//do nothing since we didn't want this method in the first place!
}
}

The other option is to define a new interface with just registClass method and use it in PartStudent class. But this defeats the purpose of having a common interface.

This is a good example of how our interface has become 'Fat' or 'Polluted'. It is exposing 2 different methods which its clients are forced to honor. This violates the ISP.

Lets see how we can correct this.

We separate out the 2 functions into different interfaces now,

interface IRegisterClass {
public void registerClass();
}
interface IAuditClass {
public auditClass();
}

This allows the FullStudent and PartStudent to be defined as following:
 
 
 
[[Image:Figure 3Class diagram for FullStudent (conforms to ISP).png]]
 
 
 

class FullStudent extends Student implements IRegisterClass, IAuditClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
public void auditClass()
{
//allow a student to audit an enrolled class
}
}
 
 
 
[[Image:Figure 4Class diagram for PartStudent (conforms to ISP).png]]
 
 
 
class PartStudent extends Student implements IRegisterClass
{
public void registerClass()
{
//allow a student to register for a particular class
}
}
This gives a clean and correct way in which the PartStudent class is not forced to depend on an interface it does not want.

==Conclusion==
#Fat Interfaces are the interfaces that are not specific to a single client. Fat interfaces lead to unintended couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, through multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that resolve the unwanted coupling between clients. Thus maintaining loose coupling and high cohesion, which is an essential attribute of good software design.
#Interfaces containing methods that are not specific to a particular type of service are called polluted or fat interfaces. These must be avoided.

==See Also==
#[http://www.oodesign.com/design-principles.html Design principles]
#[http://java.sys-con.com/node/84633/print Three Sources of a Solid Object-Oriented Design]
#[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Principles of OOD]
#[http://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes episode on SOLID]

==External References==
<ol>
<li> [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]</li>
<li> [http://www.objectmentor.com Design Principles and Design Patterns, Robert C Martin]</li>
<li> [http://ontwik.com/ruby/sandi-metz-solid-object-oriented-design/ 2009 Gotham Ruby Conference, presentation on SOLID Object Oriented Design by Sandi Metz, Duke University.]</li>
<ol>

CSC/ECE 517 Fall 2010/ch2 2d dg

2010-09-23T01:07:25Z

Gstungat:

Scaffolding in Web Application Frameworks

__TOC__
=Overview=
==Scaffolding in General==

Scaffolding in education is basically the support a teacher gives to a new student to get him started on his subject. Scaffolding is also the temporary structure often used by workers in construction.
So what we know of the word scaffolding in real world – a temporary structure to lean on while you build the main structure. The temporary structure can then be discarded.

==Scaffolding in Programming==

It is with the same basic idea that scaffolding in web programming frameworks refer to. It refers to a temporary structure, which is useful as a starting point for developing an application.
Scaffolding is nothing but a basic structure that helps a new programmer to get started quickly. It is meta-programming method to quickly generate a functioning web application with the CRUD functionality. Any web application that interacts with database has 4 basic functions generally called CRUD, which it always needs and these are:

* Create,
* Read,
* Update or
* Delete a record.

A scaffold will generate a functioning web application that allows you to carry out these functions. Usually you get a running web application with not more than a few lines of code.
It generates for you what is often termed as boilerplate code. In a MVC framework, scaffolding will usually create basic model, views and controllers and also the database objects needed.

==Features of Scaffolding==

In software applications, we need to use a number of frameworks to make application run. The frameworks may include:

* Database access
* Screen design, and
* Business rules

And scaffolding is the mechanism by which we can create the skeletal of the web application at first go.
So, now after having some basic concept of scaffolding, we can list out the main features of scaffolding below,

* It is a framework that provides the minimal setup of the components like database, application servers, and web servers.
* When you want to use the structure early on in the development cycle when you are experimenting with the database schema and layout, it helps to quickly generate basic functional application for you directly from the database schema.
* Scaffolding helps when the schema undergoes refinement and you don't need to waste your time to change the views and controllers explicitly to align with the change.
* It isn't what you would like to use directly in your production systems, you can eventually make changes as you move on with your added and updated project requirements.

=History of Scaffolding=
==Origin and Evolution==
===Scaffolding Theory===

Scaffolding theory in education came into being in 1950, by, Jerome Bruner, where he described the various scaffolding techniques for oral language and written vocabulary.
In Oral scaffolding, parents and adults help the children to make them know how to speak and communicate, how they should use the words and develop the base or a temporary framework for their children to walk in the new world. And once the child secures the control over the things, the support can be taken away. Similarly, in written scaffolding, typical supporting instructions were given by the instructor to the students to learn vocabulary, to calibrate the task, to identify the task and work independently on the task, in this way they built the scaffold for them on which they can lean on while learning.
So children use oral scaffolding as a vehicle to communicate and written scaffolding as tool for new thinking. And the teacher’s instructions also get changed from time to time, starting from the directions, to suggestions, to encouragement, and then observation.

===Scaffolding Origin in Web Applications===

Scaffolding has been around in various forms for some time. Earlier, separate code generators were written, which would generate CRUD functionality for certain frameworks. They were often the third party generators which offered varying capabilities and mainly acted as database code generators.

You could also have custom scripts, which could generate the CRUD screens from some database specifications. Often each new project involved writing up some templates to get the basic functionality or writing a template generator script, which created these templates for a project. But these generators and scripts were non-standardized and often viewed as taking time away from the core development of an application.

==What Scaffolding is Today?==
===Current Scaffolding Scope===

Scaffolding is now a part of many web application frameworks. We can find a number of development software’s that uses web application scaffolding approach. Frameworks include,

*Ruby on Rails,
*CakePHP ,
*ASP.NET
*CodeIgniter
*iPhone Web Scaffolding
*Grails

These frameworks actually contain some software components that create the skeletal attachments to the application’s database and other external devices.
We will see how this scaffolding works in some of the frameworks described above in next few paragraphs.

===Benefits of Scaffolding===

We have noticed that scaffolding makes the developers job easier, and rather than making a lot of configuration changes at the very first time or may be at the time of updations, he can concentrate on the business logic of the application, which saves lot of time that he may have spent in creating and maintaining the database code. So you can read out the benefits of Scaffolding below,

*It acts as a tool for the developers to quickly generate running web application environment for the Internet.
*It provides modular stubs to perform typical CRUD implementations.
*It improves development productivity for system architects.
*It improves efficiency by creating reusable components for developers by using frameworks and code generators.

=Scaffolding in MVC based Web Frameworks=

First we will describe how the scaffolding approach works in Rails framework. Scaffolding gets its popularity with the rails framework only, and it comes as the inbuilt feature of the rails framework.

==Scaffolding in Rails Framework==

Now lets see how scaffolding in the rails framework helps to create the database schema at the start of an application by using very simple commands.
Rails scaffolding helps to create model, view and controllers for the new resource in a single operation.
Follow these steps in the [http://www.eclipse.org/ Eclipse IDE] to create a scaffolding of a car website. We just define some attributes of a car like its color, year and model.

Step -1. Create New Rails Project: New->New Rails Project

Step -2. Get the generator view: Window->Show View->Generators

Step -3. Make sure current project for Generator is the project that you want.

Step -4. Select the scaffold generator from drop down box: Generator->scaffold

Step -5. In parameters, specify the model, fields and their type
Here we take, Car color:string maker:string year:date

Step -6. This will run the generate script and create files in View, controllers, model, db etc as shown below:

<pre>
>script/generate scaffold Car color:string maker:string model:number year:date

exists app/models/
exists app/controllers/
exists app/helpers/
create app/views/cars
exists app/views/layouts/
exists test/functional/
exists test/unit/
exists test/unit/helpers/
exists public/stylesheets/
create app/views/cars/index.html.erb
create app/views/cars/show.html.erb
create app/views/cars/new.html.erb
create app/views/cars/edit.html.erb
create app/views/layouts/cars.html.erb
create public/stylesheets/scaffold.css
create app/controllers/cars_controller.rb
create test/functional/cars_controller_test.rb
create app/helpers/cars_helper.rb
create test/unit/helpers/cars_helper_test.rb
route map.resources :cars
dependency model
exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/car.rb
create test/unit/car_test.rb
create test/fixtures/cars.yml
create db/migrate
create db/migrate/20100919144829_create_cars.rb
</pre>

It creates the db migrate file for the given model.
This creates the schema in db/migrate/2002301293_create_cars.rb file

<pre>
class CreateCars < ActiveRecord::Migration
def self.up
create_table :cars do |t|
t.string :color
t.string :maker
t.number :model
t.date :year
t.timestamps
end
end

def self.down
drop_table :cars

end
end
</pre>
Step -7 You then run a rake task to actually create the database tables using the migrate file.

Step -8 Now go to Window->Show View->Rake

Step -9 In the Rake window, select migrate task from the drop down box and run it.

You can also right click the
* create_cars.rb file,
* select the rake menu option and
* then select migrate option.
<pre>
rake db:migrate
</pre>
Step -10 You can then go to your sqlite database and check that tables have been created.

Scaffold will always generate the tables in the Development database.
With this you now have a functioning application. Start the web server and point your browser to http://localhost:3000/cars (unless you decided to override the defaults). You will be presented with a basic screen showing all the cars and their details. Links to web pages to add, edit and destroy a record are also provided. Using these, you can modify existing records or add new records.
Sample auto generated code for the above example is as below.

Controller for car in cars_controller.rb
<pre>
class CarsController < ApplicationController
# GET /cars
# GET /cars.xml
def index
@cars = Car.all

respond_to do |format|
format.html # index.html.erb
format.xml { render :xml => @cars }
end
end

# GET /cars/1
# GET /cars/1.xml
def show
@car = Car.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.xml { render :xml => @car }
end
end

# GET /cars/new
# GET /cars/new.xml
def new
@car = Car.new

respond_to do |format|
format.html # new.html.erb
format.xml { render :xml => @car }
end
end

# GET /cars/1/edit
def edit
@car = Car.find(params[:id])
end

# POST /cars
# POST /cars.xml
def create
@car = Car.new(params[:car])

respond_to do |format|
if @car.save
format.html { redirect_to(@car, :notice => 'Car was successfully created.') }
format.xml { render :xml => @car, :status => :created, :location => @car }
else
format.html { render :action => "new" }
format.xml { render :xml => @car.errors, :status => :unprocessable_entity }
end
end
end

# PUT /cars/1
# PUT /cars/1.xml
def update
@car = Car.find(params[:id])

respond_to do |format|
if @car.update_attributes(params[:car])
format.html { redirect_to(@car, :notice => 'Car was successfully updated.') }
format.xml { head :ok }
else
format.html { render :action => "edit" }
format.xml { render :xml => @car.errors, :status => :unprocessable_entity }
end
end
end

# DELETE /cars/1
# DELETE /cars/1.xml
def destroy
@car = Car.find(params[:id])
@car.destroy

respond_to do |format|
format.html { redirect_to(cars_url) }
format.xml { head :ok }
end
end
end
</pre>

Sample view file for EDIT generated in views->cars->edit.html.erb
<pre>
<h1>Editing car</h1>

<% form_for(@car) do |f| %>
<%= f.error_messages %>


<%= f.label :color %> 
<%= f.text_field :color %>


<%= f.label :maker %> 
<%= f.text_field :maker %>


<%= f.label :model %> 
<%= f.text_field :model %>


<%= f.label :year %> 
<%= f.date_select :year %>


<%= f.submit 'Update' %>

<% end %>

<%= link_to 'Show', @car %> |
<%= link_to 'Back', cars_path %>
</pre>

Database migrate file generated in db->migrate
<pre>
class CreateCars < ActiveRecord::Migration
def self.up
create_table :cars do |t|
t.string :color
t.string :maker
t.integer :model
t.date :year

t.timestamps
end
end

def self.down
drop_table :cars
end
end
</pre>

Database schema generated in db->schema.rb file
<pre>
ActiveRecord::Schema.define(:version => 20100919144829) do

create_table "cars", :force => true do |t|
t.string "color"
t.string "maker"
t.integer "model"
t.date "year"
t.datetime "created_at"
t.datetime "updated_at"
end

end
</pre>

==Dynamic Scaffolding in CakePHP==

Scaffolding in CakePHP is a little more limited than Rails. Unlike Rails, database tables and schema are created separately in CakePHP. It follows the dynamic scaffolding paradigm where you don't need to run an external command to generate the scaffolded code, what is needed is just to define the $scaffold variable and scaffolding is taken care of.

Steps for code generation in CakePHP

Step -1 Create the database schema and the tables.

Step -2 Each table that has to be scaffolded should have a corresponding controller.

Step -3 That controller must define the variable $scaffold
For eg, considering our cars example, lets say we have a cars controller-

<pre>
<?php
class CarsController extends AppController
{
var $scaffold;
}
?>
</pre>
This will go in CarsController.php in app/controllers directory.
That is all that is required. The framework will now auto-generate the basic functionality for create, update, delete.

==Other Examples==
A more detailed listing of examples of scaffolding in various other web frameworks can be found in last year's treatment of the same topic here.

http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_9_ss

==See Also==
You can go through some of the other frameworks to create scaffold web applications.
# [http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm CakePHP Framework]
# [http://www.grails.org/Scaffolding Grails Framework]
#[http://msdn.microsoft.com/en-us/library/ee377606.aspx ASP.NET Framework]
#[http://www.ntchosting.com/php/frameworks/codeigniter/ Codeigniter]
#[http://www.myeclipseide.com/me4s/features/iphone-scaffolding.php iPhone]
#[http://wiki.netbeans.org/JsfCrudGenerator70 NetBeans CRUD Generator]

=Bibiliography=
==References==

#Programming Ruby(2nd Edition): The Pragmatic Programmers' Guide (Pragmatic Programmers Series), by Dave Thomas, Andy Hunt, Andrew Hunt, Chad Fowler, Chad Fowler: Publisher: Pragmatic Bookshelf
#Agile Web Development with Rails, 3rd ed. by Dave Thomas, David Heinemeier Hansson, David Hansson, Publisher: Pragmatic Bookshelf
#http://msdn.microsoft.com/en-us/library/cc488469.aspx
#http://guides.rubyonrails.org/getting_started.html

==External Sites==

#http://en.wikipedia.org/wiki/Scaffolding_Theory
#http://www.wisegeek.com/what-is-web-application-scaffolding.htm
#http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm
#http://cpan.uwinnipeg.ca/htdocs/Scaffold/Scaffold.html

==MediaSite==

# http://www.asp.net/aspnet-in-net-35-sp1/videos/getting-started-with-dynamic-data
#http://www.youtube.com/watch?v=zV6aueUh8Bs
#http://www.youtube.com/watch?v=LWoCfTyWG_E

CSC/ECE 517 Fall 2010/ch2 2d dg

2010-09-22T21:29:11Z

Gstungat:

Scaffolding

CSC/ECE 517 Fall 2010/ch1 2d dg

2010-09-22T21:25:02Z

Gstungat:

User:Gstungat

2010-09-20T23:45:26Z

Gstungat:

ftfgcvcv

CSC/ECE 517 Fall 2010/ch1 2d dg

2010-09-20T23:39:03Z

Gstungat:

Contents:
1. What is Scaffolding
[[Introduction]]
== Introduction ==

CSC/ECE 517 Fall 2010/ch1 2d dg

2010-09-20T23:38:22Z

Gstungat:

== Headline text ==
[[One]]
Contents:
1. What is Scaffolding
[[Introduction]]
== Introduction ==

CSC/ECE 517 Fall 2010/ch1 2d dg

2010-09-20T23:37:18Z

Gstungat:

Contents:
1. What is Scaffolding
[[Introduction]]
== Introduction ==

--[[User:Gstungat|Gstungat]] 19:37, 20 September 2010 (EDT)Introduction

CSC/ECE 517 Fall 2010/ch1 2d dg

2010-09-20T23:36:48Z

Gstungat:

Contents:
1. What is Scaffolding
[[Introduction]]
== Introduction ==

Introduction

CSC/ECE 517 Fall 2010/ch1 2d dg

2010-09-20T23:34:34Z

Gstungat:

Contents:
1. What is Scaffolding
[[Media:Example.ogg]]
[[Introduction]]

Introduction

CSC/ECE 517 Fall 2010/ch1 2d dg

2010-09-20T23:31:21Z

Gstungat:

Contents:
1. What is Scaffolding

CSC/ECE 517 Fall 2010/ch1 2d dg

2010-09-20T23:29:05Z

Gstungat: Scaffolding in Web Application Frameworks

Scaffolding basics