Revision as of 23:22, 3 October 2012

A brief introduction to your article. The table of contents, which is generated automatically, will show up just below this introduction.

Overview/Introduction

Redirection in ruby refers to the where a user is redirected from one page to another.As the http requests are stateless, hence this leads to losing all the state that we had before. Thus Rails provides a hash called Flash such that it persists until the end of the next request received. Also there is a session hash, which unlike flash persists forever. <ref>http://www.youtube.com/watch?v=0m8lmRwS7E0</ref>.

For information on how to format the text of your article, create tables, and use section headings and references, see this article.

Flash in Ruby

Flash in ruby helps to remember the state until the end of the next request. It is basically used to store error messages as warnings and information as notice in the hash. This is used in views to print the error messages or notice. Instead of notice or warnings, we can define user defined hash and print its value in the view as we did for the notice and warnings. Basically it helps in flashing messages on the views.

Session in Ruby

In Ruby session persists forever and is stored in the browser cookies by default. The session data can thus be deleted by clearing content of the cookies. Session is useful when we have to remember the state for a long time. Examples include Authentication where the user enters its login id and password that needs to be available for the whole session that the user is logged in. There are some alternative storage modes for session such as Storage table or No SQL data structure.

Development of the concept your article describes can be created in sections and subsections.

Various uses of Session/Flash

Create as many sections and subsections as necessary to support your article.

Session

Session stores small amount of data that persists between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms such as cookies, tables, cache, memcache etc The session stores session id in cookies as it is insecure when embedded in the url.This unique id is used to look up the session data on its storage locations such as cookies, database tables, no sql data structure, cache etc.The data storage in cookies by default makes the session lightweight and easy to access ad it does not requires calls to the storage locations for accessing the session data. The cookie data is not encrypted but it cannot be edited by being visible in the url The CookieStore can store around 4kB of data — much less than the others — but this is usually enough. Storing large amounts of data in the session is discouraged no matter which session store your application uses. You should especially avoid storing complex objects (anything other than basic Ruby objects, the most common example being model instances) in the session, as the server might not be able to reassemble them between requests, which will result in an error. If your user sessions don’t store critical data or don’t need to be around for long periods (for instance if you just use the flash for messaging), you can consider using ActionDispatch::Session::CacheStore. This will store sessions using the cache implementation you have configured for your application. The advantage of this is that you can use your existing cache infrastructure for storing sessions without requiring any additional setup or administration. The downside, of course, is that the sessions will be ephemeral and could disappear at any time.