mirror of https://github.com/vapor/docs.git
commit
bdf60802a9
|
|
@ -41,7 +41,7 @@ The compiler will inform you that some methods need to be implemented to conform
|
|||
|
||||
### ID
|
||||
|
||||
The first required property is an identifier. This property will contain the identifier when the model is fetched from the database. If it is nil, it will be set when the model is saved.
|
||||
The first required property is an identifier. This property will contain the identifier when the model is fetched from the database. If it is `nil`, it will be set when the model is saved.
|
||||
|
||||
```swift
|
||||
final class User: Model {
|
||||
|
|
@ -68,7 +68,7 @@ The keys `id` and `name` are what we expect the columns or fields in the databas
|
|||
|
||||
### Node Representable
|
||||
|
||||
Now that we have covered initializing the model, we need to show it how to save back into the database. Model uses `NodeRepresentable` to achieve this.
|
||||
Now that we have covered initializing the model, we need to show how to save it back into the database. Model uses `NodeRepresentable` to achieve this.
|
||||
|
||||
```swift
|
||||
final class User: Model {
|
||||
|
|
|
|||
|
|
@ -111,12 +111,12 @@ Note: Certain port numbers require super user access to bind. Simply run `sudo v
|
|||
|
||||
## Note for sudo usage
|
||||
|
||||
In some linux based system, you might get error while using sudo. In that case, if you need to run the server as root, at first switch the user using this command:
|
||||
On some Linux based systems, you might get an error while using sudo. In that case, if you need to run the server as root, at first switch the user using this command:
|
||||
|
||||
```
|
||||
sudo -i
|
||||
```
|
||||
Then either add the previously installed path of swift to the root users $PATH variable.
|
||||
Then either add the previously installed path of Swift to the root users $PATH variable.
|
||||
|
||||
```
|
||||
PATH=$PATH:/your_path_to_swift
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ currentMenu: guide-commands
|
|||
---
|
||||
|
||||
# Commands
|
||||
Custom console commands on vapor are a breeze.
|
||||
Custom console commands on Vapor are a breeze.
|
||||
|
||||
## Example
|
||||
To make a custom console command we must first create a new .swift file, import Vapor and Console, and implement the Command protocol.
|
||||
To make a custom console command we must first create a new `.swift` file, import `Vapor` and `Console`, and implement the `Command` protocol.
|
||||
|
||||
```swift
|
||||
import Vapor
|
||||
|
|
@ -28,17 +28,17 @@ final class MyCustomCommand: Command {
|
|||
```
|
||||
|
||||
- The **id** property is the string you will type in the console to access the command. `.build/debug/App command` will run the Custom Command.
|
||||
- The **help** property is the help message that will give your custom command's users some idea as to how to access it.
|
||||
- The **help** property is the help message that will give your custom command's users some idea of how to access it.
|
||||
- The **console** property is the object passed to your custom command that adheres to the console protocol, allowing manipulation of the console.
|
||||
- The **run** method is where you put the logic relating to your command.
|
||||
|
||||
After we work our magic in the Custom Command file, we switch over to our main.swift file and add the custom command to the droplet like so.
|
||||
After we work our magic in the Custom Command file, we switch over to our `main.swift` file and add the custom command to the droplet like so.
|
||||
```swift
|
||||
drop.commands.append(MyCustomCommand(console: drop.console))
|
||||
```
|
||||
This allows vapor access to our custom command and lets it know to display it in the --help section of the program.
|
||||
This allows Vapor access to our custom command and lets it know to display it in the `--help` section of the program.
|
||||
|
||||
After compiling the application we can run our custom command like so
|
||||
After compiling the application we can run our custom command like so.
|
||||
|
||||
```
|
||||
.build/debug/App command
|
||||
|
|
|
|||
|
|
@ -77,12 +77,12 @@ let name = drop.config["keys", "test-names", 0]?.string ?? "default"
|
|||
Or our mongo url:
|
||||
|
||||
```swift
|
||||
let mongoUrl = drop.config["keys", "mongo", "url"].?string ?? "default"
|
||||
let mongoUrl = drop.config["keys", "mongo", "url"]?.string ?? "default"
|
||||
```
|
||||
|
||||
## Advanced Configurations
|
||||
|
||||
Having the default servers.json is great, but what about more complex scenarios. For example, what if we want a different host in production and in development? These complex scenarios can be achieved by adding additional folder structure to our Config/ directory. Here's an example of a folder structure that's setup for production and development environments.
|
||||
Having the default `servers.json` is great, but what about more complex scenarios. For example, what if we want a different host in production and in development? These complex scenarios can be achieved by adding additional folders to our `Config/` directory. Here's an example of a folder structure that's setup for production and development environments.
|
||||
|
||||
```bash
|
||||
WorkingDirectory/
|
||||
|
|
@ -111,7 +111,7 @@ Config files will be accessed in the following priority.
|
|||
3. Config/name-of-environment/
|
||||
4. Config/
|
||||
|
||||
What this means is that if a user calls `app.config["servers", "host"]`, the key will be searched in the cli first, then the secrets directory, then the top level default configs.
|
||||
What this means is that if a user calls `app.config["servers", "host"]`, the key will be searched in the CLI first, then the `secrets/` directory, then the top level default configs.
|
||||
|
||||
> `secrets/` directory should very likely be added to the gitignore.
|
||||
|
||||
|
|
@ -119,7 +119,7 @@ What this means is that if a user calls `app.config["servers", "host"]`, the key
|
|||
|
||||
Let's start with the following JSON files.
|
||||
|
||||
#### servers.json
|
||||
#### `servers.json`
|
||||
|
||||
```JSON
|
||||
{
|
||||
|
|
@ -143,7 +143,7 @@ Let's start with the following JSON files.
|
|||
|
||||
> The `"$NAME"` syntax is available for all values to access environment variables.
|
||||
|
||||
Please notice that servers.json, and production/servers.json both declare the same keys. host, and port. In our application, we'll call:
|
||||
Please notice that `servers.json`, and `production/servers.json` both declare the same keys: `host`, and `port`. In our application, we'll call:
|
||||
|
||||
```swift
|
||||
// will load 0.0.0.0 or 127.0.0.1 based on above config
|
||||
|
|
@ -154,7 +154,7 @@ let port = drop.config["servers", "http", "port"]?.int ?? 9000
|
|||
|
||||
## COMMAND LINE
|
||||
|
||||
In addition to json files nested within the Config/ directory, we can also use the command line to pass arguments into our config. By default, these values will be set as the "cli" file, but more complex options are also available.
|
||||
In addition to json files nested within the `Config/` directory, we can also use the command line to pass arguments into our config. By default, these values will be set as the "cli" file, but more complex options are also available.
|
||||
|
||||
#### 1. `--KEY=VALUE`
|
||||
|
||||
|
|
@ -170,7 +170,7 @@ would be accessible within your application by using the following:
|
|||
let mongoPassword = drop.config["cli", "mongo-password"]?.string
|
||||
```
|
||||
|
||||
#### 2. --CONFIG:FILE-NAME.KEY=CUSTOM-VALUE
|
||||
#### 2. `--CONFIG:FILE-NAME.KEY=CUSTOM-VALUE`
|
||||
|
||||
If you want command line arguments set to a file besides "cli", you can use this more advanced specification. For example, the following CLI command:
|
||||
|
||||
|
|
|
|||
|
|
@ -132,8 +132,8 @@ drop.resource("users", users)
|
|||
|
||||
## Folder
|
||||
|
||||
Controllers can go anywhere in your application, but they are most often stored in the `Controllers/*` directory.
|
||||
Controllers can go anywhere in your application, but they are most often stored in the `Controllers/` directory.
|
||||
|
||||
### Modules
|
||||
|
||||
If you are building a large application, you may want to create your controllers in a separate module. This will allow you to perform unit tests on your controllers. For more information on creating modules, visit the documentation for the [Swift Package Manager](https://swift.org/package-manager/)
|
||||
If you are building a large application, you may want to create your controllers in a separate module. This will allow you to perform unit tests on your controllers. For more information on creating modules, visit the documentation for the [Swift Package Manager](https://swift.org/package-manager/).
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Leaf Tags are made up of 4 Elements:
|
|||
- Token: `#` is the Token
|
||||
- Name: A `string` that identifies the tag
|
||||
- Parameter List: `()` May accept 0 or more arguments
|
||||
- Body(optional): `{}` Must be separated from the Parameter List by a space
|
||||
- Body (optional): `{}` Must be separated from the Parameter List by a space
|
||||
|
||||
There can be many different usages of these 4 elements depending on the Tag's implementation. Let's look at a few examples of how Leaf's built-in Tags might be used:
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ There can be many different usages of these 4 elements depending on the Tag's im
|
|||
|
||||
### Using the `#` token in HTML
|
||||
|
||||
The token cannot be escaped. Use the `#()` or `#raw() {}` Tag to output a `#` in a Leaf Template. `#()` => `#`
|
||||
The `#` token cannot be escaped. Use the `#()` or `#raw() {}` Tag to output a `#` in a Leaf Template. `#()` => `#`
|
||||
|
||||
### Raw HTML
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ currentMenu: guide-middleware
|
|||
|
||||
Middleware is an essential part of any modern web framework. It allows you to modify requests and responses as they pass between the client and your server.
|
||||
|
||||
You can imagine middleware as a chain of logic connection your server to the client requesting your web app.
|
||||
You can imagine middleware as a chain of logic connecting your server to the client requesting your web app.
|
||||
|
||||
## Basic
|
||||
|
||||
|
|
@ -136,7 +136,7 @@ Interestingly, this is how `Abort` itself is implemented in Vapor. `AbortMiddlew
|
|||
|
||||
## Configuration
|
||||
|
||||
Appending middleware ot the `drop.middleware` array is the simplest way to add middleware--it will be used every time the application starts.
|
||||
Appending middleware to the `drop.middleware` array is the simplest way to add middleware--it will be used every time the application starts.
|
||||
|
||||
You can also use the [configuration](config.md) files to enabled or disable middleware for more control. This is especially useful if you have middleware that should, for example, run only in production.
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ let name: Valid<Count<String>> = try "Vapor".validated(by: Count.max(5))
|
|||
|
||||
Here we are validating that the `String` is at most 5 characters long. The type of `Valid<Count>` tells us that the string has been validated to be a certain count, but it does not tell us exactly what that count was. The string could have been validated to be less than three characters or more than one million.
|
||||
|
||||
Because of this, `Validators` themselves are not as type safe as some applications might desire. `ValidationSuites` fix this. They combine multiple `Validators` and/or `ValidationSuites` together to represent exactly what type of data should be considered valid
|
||||
Because of this, `Validators` themselves are not as type safe as some applications might desire. `ValidationSuites` fix this. They combine multiple `Validators` and/or `ValidationSuites` together to represent exactly what type of data should be considered valid.
|
||||
|
||||
## Custom Validator
|
||||
|
||||
|
|
@ -68,9 +68,9 @@ class Name: ValidationSuite {
|
|||
}
|
||||
```
|
||||
|
||||
You only have to implement one method. In this method, use any other validators or logic to create your custom validator. Here we are defining a Name as only accepting alphanumeric Strings that are between 5 and 20 characters.
|
||||
You only have to implement one method. In this method, use any other validators or logic to create your custom validator. Here we are defining a `Name` as only accepting alphanumeric Strings that are between 5 and 20 characters.
|
||||
|
||||
Now we can be sure that anything of type Valid<Name> follows these rules.
|
||||
Now we can be sure that anything of type `Valid<Name>` follows these rules.
|
||||
|
||||
## Combining Validators
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ drop.view = LeafRenderer(viewsDir: drop.viewsDir)
|
|||
|
||||
## Available Renderers
|
||||
|
||||
These renderers can be added to your application through Providers.
|
||||
These renderers can be added to your application through [Providers](provider.md).
|
||||
|
||||
- [Leaf](https://github.com/vapor/leaf)
|
||||
- [Mustache](https://github.com/vapor/mustache-provider)
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ currentMenu: http-responder
|
|||
|
||||
# Responder
|
||||
|
||||
The `Responder` is a simple protocol defining the behavior of objects that can accept a `Request` and return a `Response`. Most notably in Vapor, it is the core api endpoint that connects the `Droplet` to the `Server`. Let's look at the definition:
|
||||
The `Responder` is a simple protocol defining the behavior of objects that can accept a `Request` and return a `Response`. Most notably in Vapor, it is the core API endpoint that connects the `Droplet` to the `Server`. Let's look at the definition:
|
||||
|
||||
```swift
|
||||
public protocol Responder {
|
||||
|
|
@ -76,4 +76,4 @@ This can be used as a jumping off point for applications looking to implement fe
|
|||
|
||||
## Client
|
||||
|
||||
The `HTTP.Client` is itself a `Responder` although, instead of handling the `Request` itself, it passes it on to the underlying uri.
|
||||
The `HTTP.Client` is itself a `Responder` although, instead of handling the `Request` itself, it passes it on to the underlying URI.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ currentMenu: http-response-representable
|
|||
|
||||
# ResponseRepresentable
|
||||
|
||||
Traditionally HTTP servers take a `Request` and return a `Response`. Vapor is no different, but we can take advantage of Swift's powerful protocols to be a bit more flexible to the user facing api.
|
||||
Traditionally HTTP servers take a `Request` and return a `Response`. Vapor is no different, but we can take advantage of Swift's powerful protocols to be a bit more flexible to the user facing API.
|
||||
|
||||
Let's start with the definition of `ResponseRepresentable`
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ currentMenu: routing-basic
|
|||
|
||||
Routing is one of the most critical parts of a web framework. The router decides which requests get which responses.
|
||||
|
||||
Vapor has a plethora of functionality for routing including route builders, groups, and collections. In this section, we will look at the basic of routing.
|
||||
Vapor has a plethora of functionality for routing including route builders, groups, and collections. In this section, we will look at the basics of routing.
|
||||
|
||||
## Register
|
||||
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ From there you can create routes with the `builder` as usual. The `builder: B` w
|
|||
|
||||
## Empty Initializable
|
||||
|
||||
You can even add `EmptyInitializable` to your route collection if it has an empty init method. This will allow you to add the route collection via its type name.
|
||||
You can even add `EmptyInitializable` to your route collection if it has an empty `init` method. This will allow you to add the route collection via its type name.
|
||||
|
||||
```swift
|
||||
class V1Collection: RouteCollection, EmptyInitializable {
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ drop.group(AuthMiddleware()) { authorized in
|
|||
|
||||
You can limit the host for a group of routes.
|
||||
|
||||
```
|
||||
```swift
|
||||
drop.group(host: "vapor.codes") { vapor
|
||||
vapor.get { request in
|
||||
// only responds to requests to vapor.codes
|
||||
|
|
|
|||
|
|
@ -12,10 +12,10 @@ Optional syntax is the easiest way to handle optional query parameters.
|
|||
|
||||
```swift
|
||||
drop.get("comments") { request in
|
||||
if let rating = request.query?["rating"]?.int {
|
||||
return "You requested comments with rating greater than #\(rating)"
|
||||
}
|
||||
return "You requested all comments"
|
||||
if let rating = request.query?["rating"]?.int {
|
||||
return "You requested comments with rating greater than #\(rating)"
|
||||
}
|
||||
return "You requested all comments"
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -26,9 +26,9 @@ To use this syntax first we need to ensure the query object is present with a `g
|
|||
|
||||
```swift
|
||||
drop.get("comments") { request in
|
||||
guard let rating = request.query?["rating"]?.int else {
|
||||
throw Abort.custom(status: .preconditionFailed, message: "Please include a rating")
|
||||
}
|
||||
return "You requested comments with rating greater than #\(rating)"
|
||||
guard let rating = request.query?["rating"]?.int else {
|
||||
throw Abort.custom(status: .preconditionFailed, message: "Please include a rating")
|
||||
}
|
||||
return "You requested comments with rating greater than #\(rating)"
|
||||
}
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue