RORAccording to rubyonrails.org

"Rails is a full-stack framework for developing database-backed web applications according to the Model-View-Control pattern. From the Ajax in the view, to the request and response in the controller, to the domain model wrapping the database, Rails gives you a pure-Ruby development environment. To go live, all you need to add is a database and a web server."

A good tutorial for basic learning of ROR can be found at http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html


8 thoughts on “Rails”

  1. Himanshu Joshi said:

    Few common conventions suggested evry next time while creating a best practice code in RoR :

    1. Stick to the Conventions.
    2. Don’t Repeat Yourself.
    3. Refactoring.
    4. Validations must be the part of model.
    5. Keep the Logic in Models.
    6. The database script should be available with migrations.
    7. Inheritance and Relationships between tables must be defined in Models.
    8.Test-Driven Development, that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test.
    9. Performance testing should be done in the production environment, as this adds some optimizations which are usually turned off in the development environment. Its a last thing to be suggested….. when u r abt to make a launch of ur application.

    “Stick to the Conventions”
    It means how we name our…..models, controllers, views, test, ……………….., database, table, fields………….

    “keep the logic in model”
    It seems many beginners have difficulty determining what code to place in models. As a result, the models are very small but the views and controllers are littered with business logic. More often than not, if you can move something out of the view/controller and into a model, you should! This has many benefits, including slimming down the views/controllers, removing duplication, and making it easier to test this logic.

    “Refactoring” is used to improve the design of existing code without changing its functionality. Keeping the logic in models can also be helpful in refactoring.

    Looking forward to som1 complete the list of common conventions……….

  2. raghavendra said:

    Validations Must Be Part Of Model

    try the above given link

    Validators are tier agnostic and can be used to collaborate with multiple layers –
    * Business Layer for enforcing business logic on “semantically valid” objects
    * Persistence layer to ensure valid objects get persisted
    * MVC layer to enforce data binding from request parameters

    Validators in Spring have their lifecycles controlled through the IoC – hence these singletons can be nicely wired together through DI

    Spring MVC requires validators as separate objects

  3. Himanshu Joshi said:

    ok lets stay close to Raghavendra’s point first……..

    What is the difference of use with the following:

    1. validates_format_of :city, :with => /^([a-zA-Z])[a-zA-Z ]+$/, :if=> Proc.new { |u| u.city.size > 0}

    2. validates_format_of :city, :with => /^([a-zA-Z])[a-zA-Z ]+$/, :allow_nil => true

    Are both of them right?
    a) If yes, where to use which one.
    b) If no, how and where, correctly do we use them, i.e.
    :if=> Proc.new { |u| u.city.size > 0}
    :allow_nil => true

  4. Hey Himanshu,
    Both are doing same thing, but i would suggest to use second one, because thats the right way to do this. First one is just a work around.

  5. well in the current context both will act same. but as Akhil said 2nd one is better option here….For first one the better place to use will be when we have some other complicated condition which can not be handled by the already provided options… an example can be like…

    validates_presence_of :password, :if => Proc.new { |user| user.new_record? }

  6. Himanshu Joshi said:

    Thats a nice idea for a better coding practice……

    One more thing ……..
    validates_format_of :city, :with => /^([a-zA-Z])[a-zA-Z ]+$/, :if=> Proc.new { |u| u.city.size > 0}
    i believe this will throw an error in case we have city = nil………. for city.size………… correct me if i m wrong

    Next thing about validations …… how we need to handle multiple validation on same field………..focus is getting a single error message rather than multiple………….. like

    validates_length_of :username, :in => 6..50
    validates_format_of :username, :with => /^([a-zA-Z])[a-zA-Z0-9]+$/
    validates_uniqueness_of :username

    now for username = “abc” for an already existing username “abc” ……. how can we get a single (instead of 3) but well defined error message keeping in mind a best practice motto.

  7. Himanshu Joshi said:

    🙂 somthing on validation………

    1. validates_format_of :city, :with => /^([a-zA-Z])[a-zA-Z ]+$/, :allow_nil => true
    in the above case, the condition really works…… city is always validated ….. allow_nil => true doesnt really wrk here……… any thought why…….. if u say m wrong in saying tht…… think of any rails version dependency………

    2. on the other hand if u set the params[:city] = nil for validation condition like…
    :if=> Proc.new { |c| c.city.size > 0}
    its gonna give u an error for nil.size, but no error when params[:city] = “”

    may be if parameter is not passed its nil and if it is passed blank its “”
    so wat really is the difference between….. nil and “” values

    ………..looking fwd 4 some food for the thought.

  8. Himanshu Joshi said:

    nil doesnt specifies the type of value………. its a no value
    while “” is a blank string type value………..
    so city has to b a string value to get the size………….

    bt wat abt the :allow_nil => true ………nt wrking

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s