67f81cc72d
* Add form_with to unify form_tag/form_for. `form_tag` and `form_for` serve very similar use cases. This PR unifies that usage such that `form_with` can output just the opening form tag akin to `form_tag` and can just work with a url, for instance. `form_with` by default doesn't attach class or id to the form — removing them on fields is moved out to a default revisiting PR later. Ported over old tests where applicable to ensure maximum coverage, but left some commented out because they don't yet apply (e.g. `fields_for` later being replaced by `fields`). [ Kasper Timm Hansen & Marek Kirejczyk ] * Add fields DSL method. Strips `_for` and requires models passed as a keyword argument. * Document form_with. Graft the `form_for` docs: rewrite, revise and expand where needed. Also test that a `format` isn't used when an explicit URL is passed. * Enable remote by default. Brand new world! Forms submit via XHRs by default, woah. * Invert `include_id` to `skip_id`. `skip_id: true` reads better than `include_id: false` (since the `include_id` default is true). * Invert `remote` to `local`. Since forms are remote by default, the option name makes more sense as `local: true`. * Invert `enforce_utf8` to `skip_enforcing_utf8`. * Refer to the brand spanking new rails-ujs. Soon to be bundled in Rails proper, so jquery-ujs is out. * Make `form_with` a bit more composed. The flow is still not quite what it should be because the legacy methods and these new ones pull at opposite ends. Lots of options have been renamed, so now the new pieces don't fit in so well. I'll try to work on this in later commits after this PR (it's likely there's a much better way to structure this whole part of Action View). |
||
---|---|---|
.github | ||
actioncable | ||
actionmailer | ||
actionpack | ||
actionview | ||
activejob | ||
activemodel | ||
activerecord | ||
activesupport | ||
ci | ||
guides | ||
railties | ||
tasks | ||
tools | ||
.codeclimate.yml | ||
.gitattributes | ||
.gitignore | ||
.rubocop.yml | ||
.travis.yml | ||
.yardopts | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
Gemfile | ||
Gemfile.lock | ||
MIT-LICENSE | ||
rails.gemspec | ||
RAILS_VERSION | ||
Rakefile | ||
README.md | ||
RELEASING_RAILS.md | ||
version.rb |
Welcome to Rails
Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern.
Understanding the MVC pattern is key to understanding Rails. MVC divides your application into three layers, each with a specific responsibility.
The Model layer represents your domain model (such as Account, Product,
Person, Post, etc.) and encapsulates the business logic that is specific to
your application. In Rails, database-backed model classes are derived from
ActiveRecord::Base
. Active Record allows you to present the data from
database rows as objects and embellish these data objects with business logic
methods. You can read more about Active Record in its README.
Although most Rails models are backed by a database, models can also be ordinary
Ruby classes, or Ruby classes that implement a set of interfaces as provided by
the Active Model module. You can read more about Active Model in its README.
The Controller layer is responsible for handling incoming HTTP requests and
providing a suitable response. Usually this means returning HTML, but Rails controllers
can also generate XML, JSON, PDFs, mobile-specific views, and more. Controllers load and
manipulate models, and render view templates in order to generate the appropriate HTTP response.
In Rails, incoming requests are routed by Action Dispatch to an appropriate controller, and
controller classes are derived from ActionController::Base
. Action Dispatch and Action Controller
are bundled together in Action Pack. You can read more about Action Pack in its
README.
The View layer is composed of "templates" that are responsible for providing appropriate representations of your application's resources. Templates can come in a variety of formats, but most view templates are HTML with embedded Ruby code (ERB files). Views are typically rendered to generate a controller response, or to generate the body of an email. In Rails, View generation is handled by Action View. You can read more about Action View in its README.
Active Record, Active Model, Action Pack, and Action View can each be used independently outside Rails. In addition to that, Rails also comes with Action Mailer (README), a library to generate and send emails; Active Job (README), a framework for declaring jobs and making them run on a variety of queueing backends; Action Cable (README), a framework to integrate WebSockets with a Rails application; and Active Support (README), a collection of utility classes and standard library extensions that are useful for Rails, and may also be used independently outside Rails.
Getting Started
-
Install Rails at the command prompt if you haven't yet:
$ gem install rails
-
At the command prompt, create a new Rails application:
$ rails new myapp
where "myapp" is the application name.
-
Change directory to
myapp
and start the web server:$ cd myapp $ rails server
Run with
--help
or-h
for options. -
Using a browser, go to
http://localhost:3000
and you'll see: "Yay! You’re on Rails!" -
Follow the guidelines to start developing your application. You may find the following resources handy:
Contributing
We encourage you to contribute to Ruby on Rails! Please check out the Contributing to Ruby on Rails guide for guidelines about how to proceed. Join us!
Everyone interacting in Rails and its sub-projects' codebases, issue trackers, chat rooms, and mailing lists is expected to follow the Rails code of conduct.
Code Status
License
Ruby on Rails is released under the MIT License.