Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 1w68 ss

2012-11-20T03:50:14Z

Sbkottan: Editing SaaS - 3.16. Finishing crud - Ruby

Editing SaaS - 3.16. Finishing crud - Ruby
==CRUD==
CRUD operations are basic database operations of a persistent storage system that includes Create,Read,Update and Destroy.
In rails Create, Read, Update and Destroy are supported by many methods provided by ActiveRecord, making it independent of any database. Since Rails follows MVC(Model-View-Controller) architecture, these three parts are responsible for making all these operations possible.

====Update====
Update is used to update an existing instance record of an application. Edit/Update pair is analogous to New/Create pair. As seen in the in New/Create functionality, the first action will retrieve the form and the second action will apply the changes and results of what the user passed into the form. The submit action redirects to the show action and shows the new modified item that was updated.
For the update functionality,the Form should be available with the existing fields populated. Also,the form action uses PUT method instead of the POST method.

The code for Edit in the controller is as follows:
def edit
@movie = movie.find params[:id]
end
Here, the instance variable movie which is to be edited is replaced with the name of the movie it will be edited into.

Update looks similar to create action. The instance variable movie is first retrieved and then updated using update.attributes! where the parameters are passed in. The update.attributes! indicates that it is a destructive action.
The code for Update in the controller is as follows:
def update
@movie = movie.find params[:id]
@movie.update_attributes!(params[:movie])
flash[:notice] = ""
redirect_to movie_path(@movie)
end

In the view, a form tag is used for the movie instance. By default, the method used will be POST but we are explicitly setting the method to PUT. Sample code is as follows:
form_tag movie_path(@movie), :method => :put do
label :movie, :title, 'Title'
text_field :movie, 'title'
submit_tag 'Update Movie Info'

====Destroy====
Destroy is an instance method on a particular item. The instance variable must be loaded up first, and then it can be destroyed.
def destroy
@movie=Movie.find(params[:id])
@movie.destroy
flash[:notice]="movie '#{@movie.title}'deleted."
redirect_to movies_path
end
As seen in the code example, the instance variable of the movie is first retrieved and then destroyed using "destroy".
Also, it can be seen that when we do the Edit action we load up the instance variable and then do so again for the Update action. This is because the instance variable only persists for a certain request.

==Fallacies, pitfalls and perspectives on SaaS-on-Rails==
The MVC architectural pattern describes a way to structure our application and the responsibilities. The design also defines the way in which the three different components interact with each other.

:1. A controller can send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document). It can send commands to the model to update the model's state (e.g., editing a document).

:2. A model notifies its associated views and controllers when there has been a change in its state. This notification allows the views to produce updated output, and the controllers to change the available set of commands. A passive implementation of MVC omits these notifications, because the application does not require them or the software platform does not support them.

:3. A view requests from the model the information that it needs to generate an output representation.

Under this architectural pattern, the common pitfalls to be avoided are:

:1. Fat Controllers:
:Controller is the first place where we write code so we have to make sure that they should be as lean as possible. Fat Controllers are not recommended because business logic is enclosed in the controller and changes made are not reusable in other controllers. Also, its more difficult to port changes to other controllers, etc. when changes have to be made.

:2. Fat views:
:Its always recommended to not have the application or model logic in the view. Views, just like the controllers have to be as lean as possible. Some common mistakes in this regard can be:

::1. Including "for loops" in the view
::2. Placing the logic for sorting the list and so on..

:Essentially views are meant to serve as a structure for the display of your model data. Therefore, the view is serving its purpose if the structure it creates for the display of a specific model can be adjusted based on the data contained in the model. Conditionally displaying elements in your view based on certain properties of the model it is meant to render is an acceptable practice.

:If your view contained logic to modify the model data in any way, this would violate the separation of concerns that MVC is meant to establish.

Therefore, it is only recommended to have fat models in the application because the business logic changes will be easier to make and moreover the models become reusable in more than one controller and thus it is easier to unit test.

==Designing for Service Oriented Architecture.==

In software engineering, a service-oriented architecture (SOA) is a set of principles and methodologies for designing and developing software in the form of interoperable services. These services are well-defined business functionalities that are built as software components (discrete pieces of code and/or data structures) that can be reused for different purposes. SOA design principles are used during the phases of systems development and integration.

SOA generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well-defined interface to access them. XML is often used for interfacing with SOA services, though this is not required. JSON is also becoming increasingly common.

If the conventions mentioned in the previous section are followed, it will easily allow our application to integrate with Service Oriented Architecture. A well defined controller can be easily modified to make it amenable to Service Oriented Architecture (i.e. respond to SOA (JSON / XML) )

A simple example of the same can be seen below. Based on the client requirement, an appropriate response is generated.
def create
..
respond_to do |client_wants|
client_wants.html{ redirect_to movie_path(@movie) }
client_wants.xml{ render :xml => @movie.to_xml}
end
..
end

==Summary==

1. In rails Create, Read, Update and Destroy are supported by many methods provided by ActiveRecord, making it independent of any database. Since Rails follows MVC(Model-View-Controller) architecture, these three parts are responsible for making all these operations possible.

2. MVC Pattern encourages to include more code into the models, so that they can be reused across multiple controllers and views. This implies easier SOA Integration.

3. Rails encourages convention over configuration and follows many standard conventions. Following these avoids writing more code which indirectly leads to lesser number of bugs.

==References==
http://www.youtube.com/watch?v=P0g6JtcWm2o}

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

http://en.wikipedia.org/wiki/Service-oriented_architecture

http://en.wikipedia.org/wiki/Create,_read,_update_and_delete

http://www.rorexperts.com/crud-operations-in-rails-t2239.html

SaaS - 3.16. Finishing crud - Ruby

2012-11-20T03:44:24Z

SaaS - 3.16. Finishing crud - Ruby

2012-11-20T03:15:23Z

Sbkottan:

SaaS - 3.16. Finishing crud - Ruby

2012-11-20T02:55:39Z

Sbkottan:

==CRUD==
CRUD operations are basic database operations of a persistent storage system that includes Create,Read,Update and Destroy.

==Update==
Update is used to update an existing instance record of an application. Edit/Update pair is analogous to New/Create pair. As seen in the in New/Create functionality, the first action will retrieve the form and the second action will apply the changes and results of what the user passed into the form. The submit action redirects to the show action and shows the new modified item that was updated.
For the update functionality,the Form should be available with the existing fields populated. Also,the form action uses PUT method instead of the POST method.

The code for Edit in the controller is as follows:
def edit
@movie = movie.find params[:id]
end
Here, the instance variable movie which is to be edited is replaced with the name of the movie it will be edited into.

Update looks similar to create action. The instance variable movie is first retrieved and then updated using update.attributes! where the parameters are passed in. The update.attributes! indicates that it is a destructive action.
The code for Update in the controller is as follows:
def update
@movie = movie.find params[:id]
@movie.update_attributes!(params[:movie])
flash[:notice] = ""
redirect_to movie_path(@movie)
end

In the view, a form tag is used for the movie instance. By default, the method used will be POST but we are explicitly setting the method to PUT.
form_tag movie_path(@movie), :method => :put do
label :movie, :title, 'Title'
text_field :movie, 'title'
submit_tag 'Update Movie Info'

==Destroy==
Destroy is an instance method on a particular item. The instance variable must be loaded up first, and then it can be destroyed.
def destroy
@movie=Movie.find(params[:id])
@movie.destroy
flash[:notice]="movie '#{@movie.title}'deleted."
redirect_to movies_path
end
As seen in the code example, the instance variable of the movie is first retrieved and then destroyed using "destroy".
Also, it can be seen that when we do the Edit action we load up the instance variable and then do so again for the Update action. This is because the instance variable only persists for a certain request.

==Fallacies, pitfalls and perspectives on SaaS-on-Rails==
The MVC architectural pattern describes a way to structure our application and the responsibilities. The design also defines the way in which the three different components interact with each other.

1. A controller can send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document). It can send commands to the model to update the model's state (e.g., editing a document).

2. A model notifies its associated views and controllers when there has been a change in its state. This notification allows the views to produce updated output, and the controllers to change the available set of commands. A passive implementation of MVC omits these notifications, because the application does not require them or the software platform does not support them.

3. A view requests from the model the information that it needs to generate an output representation.

Under this architectural pattern, the common pitfalls to be avoided are:

1. Fat Controllers:
Controller is the first place where we write code so we have to make sure that they should be as lean as possible. Fat Controllers are not recommended because business logic is enclosed in the controller and changes made are not reusable in other controllers. Also, its more difficult to port changes to other controllers, etc. when changes have to be made.

2. Fat views:
Its always recommended to not have the application or model logic in the view. Views, just like the controllers have to be as lean as possible. Some common mistakes in this regard can be:

1. Including "for loops" in the view
2. Placing the logic for sorting the list and so on..

Essentially views are meant to serve as a structure for the display of your model data. Therefore, the view is serving its purpose if the structure it creates for the display of a specific model can be adjusted based on the data contained in the model. Conditionally displaying elements in your view based on certain properties of the model it is meant to render is an acceptable practice.

If your view contained logic to modify the model data in any way, this would violate the separation of concerns that MVC is meant to establish.

Therefore, it is only recommended to have fat models in the application because the business logic changes will be easier to make and moreover the models become reusable in more than one controller and thus it is easier to unit test. Moreover, following the above conventions allow our application to easily integrate with Service Oriented Architecture.

SaaS - 3.16. Finishing crud - Ruby

2012-11-20T02:53:33Z

Sbkottan: Created page with "==CRUD== CRUD operations are basic database operations of a persistent storage system that includes Create,Read,Update and Destroy. ==Update== Update is used to update an existi..."

==CRUD==
CRUD operations are basic database operations of a persistent storage system that includes Create,Read,Update and Destroy.

==Update==
Update is used to update an existing instance record of an application. Edit/Update pair is analogous to New/Create pair. As seen in the in New/Create functionality, the first action will retrieve the form and the second action will apply the changes and results of what the user passed into the form. The submit action redirects to the show action and shows the new modified item that was updated.
For the update functionality,the Form should be available with the existing fields populated. Also,the form action uses PUT method instead of the POST method.

The code for Edit in the controller is as follows:
def edit
@movie = movie.find params[:id]
end
Here, the instance variable movie which is to be edited is replaced with the name of the movie it will be edited into.

Update looks similar to create action. The instance variable movie is first retrieved and then updated using update.attributes! where the parameters are passed in. The update.attributes! indicates that it is a destructive action.
The code for Update in the controller is as follows:
def update
@movie = movie.find params[:id]
@movie.update_attributes!(params[:movie])
flash[:notice] = ""
redirect_to movie_path(@movie)
end

In the view, a form tag is used for the movie instance. By default, the method used will be POST but we are explicitly setting the method to PUT.
form_tag movie_path(@movie), :method => :put do
label :movie, :title, 'Title'
text_field :movie, 'title'
submit_tag 'Update Movie Info'

==Destroy==
Destroy is an instance method on a particular item. The instance variable must be loaded up first, and then it can be destroyed.
def destroy
@movie=Movie.find(params[:id])
@movie.destroy
flash[:notice]="movie '#{@movie.title}'deleted."
redirect_to movies_path
end
As seen in the code example, the instance variable of the movie is first retrieved and then destroyed using "destroy".
Also, it can be seen that when we do the Edit action we load up the instance variable and then do so again for the Update action. This is because the instance variable only persists for a certain request.

==Fallacies, pitfalls and perspectives on SaaS-on-Rails==
The MVC architectural pattern describes a way to structure our application and the responsibilities. The design also defines the way in which the three different components interact with each other.

1. A controller can send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document). It can send commands to the model to update the model's state (e.g., editing a document).

2. A model notifies its associated views and controllers when there has been a change in its state. This notification allows the views to produce updated output, and the controllers to change the available set of commands. A passive implementation of MVC omits these notifications, because the application does not require them or the software platform does not support them.

3. A view requests from the model the information that it needs to generate an output representation

Under this architectural pattern, the common pitfalls to be avoided are:

1. Fat Controllers:
Controller is the first place where we write code so we have to make sure that they should be as lean as possible. Fat Controllers are not recommended because business logic is enclosed in the controller and changes made are not reusable in other controllers. Also, its more difficult to port changes to other controllers, etc. when changes have to be made.
2. Fat views:
Its always recommended to not have the application or model logic in the view. Views, just like the controllers have to be as lean as possible. Some common mistakes in this regard can be:
1. Including "for loops" in the view
2. Placing the logic for sorting the list and so on..

Essentially views are meant to serve as a structure for the display of your model data. Therefore, the view is serving its purpose if the structure it creates for the display of a specific model can be adjusted based on the data contained in the model. Conditionally displaying elements in your view based on certain properties of the model it is meant to render is an acceptable practice.

If your view contained logic to modify the model data in any way, this would violate the separation of concerns that MVC is meant to establish.
Therefore, it is only recommended to have fat models in the application because the business logic changes will be easier to make and moreover the models become reusable in more than one controller and thus it is easier to unit test. Moreover, following the above conventions allow our application to easily integrate with Service Oriented Architecture.

CSC/ECE 517 Fall 2012/ch1b 1w50 1s

2012-10-06T18:59:22Z

Sbkottan: /* References */

== Importance of Design Patterns ==
Over the last few years, patterns have gained attention in the software community. The use of patterns has helped solve issues faced while designing and reusing applications and libraries. These patterns capture knowledge from various parts of software developing. But as the number of patterns increases, the need to organize the patterns becomes more important. There should be a strong classification scheme to organize patterns in a library and help users in finding and storing patterns. Developing such a classification scheme involves finding useful criteria that should reflect natural properties of patterns

== Buschman et al ==
According to Buschman, classification is based on three criteria.
The functionality criteria classifies patterns based on the specific functionality that the design pattern will be used for.
The structural principles classifies patterns based on the architectural patterns that the design pattern is utilizing.

{| class="wikitable"
|-
! Functionality !! Structural Principle
|-
| Creation || Abstraction
|-
| Communication || Encapsulation
|-
| Access || Separation of concerns
|-
| Computation of complex tasks || Coupling and cohesion
|}

Patterns which belong to the sub category ''creation'' specify the manner in which to instantiate certain complex recursive or aggregate object structures. Patterns belonging to the subcategory ''communication'' describes the communication protocol to be followed during the remote or independent development of certain collaborating objects. Patterns of the ''access'' category will describe the scope of a particular object. Patterns belonging to the category organizing the ''computation of complex tasks'' specify the way in which responsibility can be allocated among collaborating objects.

Patterns belonging to the subcategory ''abstraction'' gives an abstract overview of functionality in a software system. Patterns belonging to the subcategory ''encapsulation'' hide details of objects to eradicate dependencies.Patterns in the subcategory ''separation of concern'' segregates specific responsibilities into different objects or components to solve a particular task or provide a certain service. Patterns belonging to the category ''coupling and cohesion'' will ease out the structural and communicational dependencies between strongly coupled objects.

== Coad ==
Coad organizes his pattern classification around a certain pattern which will further serve as a template for other patterns that follow.

{| class="wikitable"
|-
! Pattern !! Description
|-
| fundamental pattern || template for other patterns
|-
| aggregate patterns || patterns that interact with transaction players
|-
| plan patterns || patterns that interact with a plan player
|-
| interaction patterns || Patterns which interact with the other players
|}

== Pree ==
Pree classification is based on the structure of the design pattern.
*Basic inheritance and interaction patterns
*Patterns for structuring object-oriented software systems
*Patterns based on recursive structures
*Patterns relying on abstract coupling
*Patterns related to the MVC-framework

== Zimmer ==
Zimmer classification provides a new classification of the GoF design pattern proposed by Gamma et all. Three kinds of relationships are defined and a pattern is categorized based on what relationship it supports.
*X uses Y in its solution
X uses a design pattern Y as part of its solution.

*Variant of X uses Y in its solution
X may or may not utilize Design pattern Y as part of its solution.

*X is similar to Y
X and Y address a similar kind of problem.

== Similarities and Differences in the Classification approach ==

In contrast to the classification by Gamma et. al, a pattern can belong to more than one category per criterion in Buschman et. al classification.
Zimmer uses the relationships that Gamma et. al describe in each pattern's "Related Patterns" section. These relationships address a wide range of issues from “the pattern uses another pattern in its solution" to “the pattern is similar to another pattern in constructing object structures". Therefore there are extensive similarities in the classification scheme.
Coad neither stress the importance of a classification nor does he describe his organization of patterns in a thorough manner.

== References==
http://www8.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm

http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch7_7f_bn

Relationships between Design Patterns-Walter Zimmer

http://www.vincehuston.org/dp/

http://www.cse.msu.edu/~cse870/Materials/Patterns/Docs/orig-patterns-paper.pdf

2012-10-04T00:05:29Z

Sbkottan: Blanked the page

1w50

2012-10-04T00:04:41Z

Sbkottan:

== weer ==
== qww ==

1w50

2012-10-04T00:04:24Z

Sbkottan: Created page with "== weer =="

== weer ==