Merge branch 'master' of github.com:laravel/laravel

taylorotwell · taylorotwell · commit c69c7cac1ae3 · 2012-10-31T08:54:26.000-05:00
diff --git a/laravel/documentation/database/eloquent.md b/laravel/documentation/database/eloquent.md
@@ -245,22 +245,24 @@ You may be wondering: _If the dynamic properties return the relationship and req
 
 Many-to-many relationships are the most complicated of the three relationships. But don't worry, you can do this. For example, assume a User has many Roles, but a Role can also belong to many Users. Three database tables must be created to accomplish this relationship: a **users** table, a **roles** table, and a **role_user** table. The structure for each table looks like this:
 
-**Users:**
+**users:**
 
 	id    - INTEGER
 	email - VARCHAR
 
-**Roles:**
+**roles:**
 
 	id   - INTEGER
 	name - VARCHAR
 
-**Role_User:**
+**role_user:**
 
     id      - INTEGER
 	user_id - INTEGER
 	role_id - INTEGER
 
+Tables contain many records and are consequently plural. Pivot tables used in **has\_many\_and\_belongs\_to** relationships are named by combining the singular names of the two related models arranged alphabetically and concatenating them with an underscore.
+
 Now you're ready to define the relationship on your models using the **has\_many\_and\_belongs\_to** method:
 
 	class User extends Eloquent {
@@ -280,7 +282,7 @@ Or, as usual, you may retrieve the relationship through the dynamic roles proper
 
 	$roles = User::find(1)->roles;
 
-As you may have noticed, the default name of the intermediate table is the singular names of the two related models arranged alphabetically and concatenated by an underscore. However, you are free to specify your own table name. Simply pass the table name in the second parameter to the **has\_and\_belongs\_to\_many** method:
+If your table names don't follow conventions, simply pass the table name in the second parameter to the **has\_and\_belongs\_to\_many** method:
 
 	class User extends Eloquent {
 
diff --git a/laravel/documentation/home.md b/laravel/documentation/home.md
@@ -29,7 +29,7 @@ There are many ways in which Laravel differentiates itself from other frameworks
 - **Reverse Routing** allows you to create links to named routes. When creating links just use the route's name and Laravel will automatically insert the correct URI.  This allows you to change your routes at a later time and Laravel will update all of the relevant links site-wide.
 - **Restful Controllers** are an optional way to separate your GET and POST request logic. In a login example your controller's get_login() action would serve up the form and your controller's post_login() action would accept the posted form, validate, and either redirect to the login form with an error message or redirect your user to their dashboard.
 - **Class Auto Loading** keeps you from having to maintain an autoloader configuration and from loading unnecessary components when they won't be used. Want to use a library or model?  Don't bother loading it, just use it. Laravel will handle the rest.
-- **View Composers** are blocks of code that can be run when a view is loaded. A good example of this would be a blog side-navigation view that contains a list of random blog posts. Your composer would contain the logic to load the blog posts so that all you have to do i load the view and it's all ready for you. This keeps you from having to make sure that your controllers load the a bunch of data from your models for views that are unrelated to that method's page content.
+- **View Composers** are blocks of code that can be run when a view is loaded. A good example of this would be a blog side-navigation view that contains a list of random blog posts. Your composer would contain the logic to load the blog posts so that all you have to do is load the view and it's all ready for you. This keeps you from having to make sure that your controllers load the a bunch of data from your models for views that are unrelated to that method's page content.
 - **The IoC container** (Inversion of Control) gives you a method for generating new objects and optionally instantiating and referencing singletons. IoC means that you'll rarely ever need to bootstrap any external libraries. It also means that you can access these objects from anywhere in your code without needing to deal with an inflexible monolithic structure. 
 - **Migrations** are version control for your database schemas and they are directly integrated into Laravel. You can both generate and run migrations using the "Artisan" command-line utility. Once another member makes schema changes you can update your local copy from the repository and run migrations. Now you're up to date, too!
 - **Unit-Testing** is an important part of Laravel. Laravel itself sports hundreds of tests to help ensure that new changes don't unexpectedly break anything. This is one of the reasons why Laravel is widely considered to have some of the most stable releases in the industry.  Laravel also makes it easy for you to write unit-tests for your own code.  You can then run tests with the "Artisan" command-line utility.
diff --git a/laravel/documentation/validation.md b/laravel/documentation/validation.md
@@ -450,4 +450,4 @@ Next, let's take our "awesome" rule and define it in our new class:
 
 Notice that the method is named using the **validate_rule** naming convention. The rule is named "awesome" so the method must be named "validate_awesome". This is one way in which registering your custom rules and extending the Validator class are different. Validator classes simply need to return true or false. That's it!
 
-Keep in mind that you'll still need to create a custom message for any validation rules that you create.  The method for doing so is the same no matter how you define your rule!
+Keep in mind that you'll still need to create a custom message for any validation rules that you create.  The method for doing so is the same no matter how you define your rule!
diff --git a/laravel/documentation/views/html.md b/laravel/documentation/views/html.md
@@ -21,11 +21,11 @@ For example, the < symbol should be converted to its entity representation. Conv
 
 #### Converting a string to its entity representation:
 
-	echo HTML::entities('<script>alert('hi');</script>');
+	echo HTML::entities('<script>alert(\'hi\');</script>');
 
 #### Using the "e" global helper:
 
-	echo e('<script>alert('hi');</script>');
+	echo e('<script>alert(\'hi\');</script>');
 
 <a name="scripts-and-style-sheets"></a>
 ## Scripts And Style Sheets
@@ -70,7 +70,7 @@ For example, the < symbol should be converted to its entity representation. Conv
 
 #### Generating a link to a named route with wildcard values:
 
-	$url = HTML::link_to_route('profile', array($username));
+	$url = HTML::link_to_route('profile', 'User Profile', array($username));
 
 *Further Reading:*
 

Original file line number	Diff line number	Diff line change
`@@ -450,4 +450,4 @@ Next, let's take our "awesome" rule and define it in our new class:`
`450`	`450`
`451`	`451`	`Notice that the method is named using the validate_rule naming convention. The rule is named "awesome" so the method must be named "validate_awesome". This is one way in which registering your custom rules and extending the Validator class are different. Validator classes simply need to return true or false. That's it!`
`452`	`452`
`453`		`-Keep in mind that you'll still need to create a custom message for any validation rules that you create. The method for doing so is the same no matter how you define your rule!`
	`453`	`+Keep in mind that you'll still need to create a custom message for any validation rules that you create. The method for doing so is the same no matter how you define your rule!`