introduction to overview

Sessions.md

@@ -0,0 +1,6 @@
+# HTTP Sessions
+
+
+## Overview
+Tba.
+

application.md

@@ -1,7 +1,7 @@
 # Application
 
 
-## Introduction
+## Overview
 Every Supercharge application (HTTP and console) relies on an `Application`. The `Application` instance in Supercharge is the central place holding your app together. Each app requires a “base path” defining the app’s root directory path. This base path tells the framework from where to boot your Supercharge app.
 
 You’ll find bootstrapping files for HTTP and console applications inside of the `bootstrap` directory. Both bootstrapping files are used by the `server.ts` and `craft.ts` files (they are in the root of your app directory). Both files then start one of the following apps:

configuration.md

@@ -1,7 +1,7 @@
 # Configuration and Environment
 
 
-## Introduction
+## Overview
 All your Supercharge configuration files are stored in the `config` directory. Your Supercharge application and the framework core follow these configuration files. You can adjust and tweak the app’s behavior using different values for individual options.
 
 

controllers.md

@@ -1,5 +1,5 @@
 # HTTP Controllers
 
 
-## Introduction
+## Overview
 tba.

craft-console.md

@@ -1,5 +1,5 @@
 # Craft Console
 
 
-## Introduction
+## Overview
 Tba.

csrf-protection.md

@@ -1,7 +1,7 @@
 # CSRF Protection
 
 
-## Introduction
+## Overview
 Supercharge has support for [cross-site request forgery](https://en.wikipedia.org/wiki/Cross-site_request_forgery) (CSRF) protection. A cross-site request forgery is a malicious exploit where unauthorized commands are transmitted on behalf of an authenticated user.
 
 Supercharge ships with CSRF protection out-of-the-box. It generates a “CSRF token” for active user sessions. To use CSRF protection, you must register the session [bootstrapper](/docs/{{version}}/bootstrappers).

database.md

@@ -1,5 +1,5 @@
 # Database
 
 
-## Introduction
+## Overview
 tba.

decorations.md

@@ -1,7 +1,7 @@
 # Decorations
 
 
-## Introduction
+## Overview
 Decorations in Supercharge describe custom functionality extending the HTTP core. You’re essentially adding your own properties or methods to the core. It’s a controlled and safe way to extend three core objects in your application:
 
 - `server`: the HTTP server instance

deployment.md

@@ -1,7 +1,7 @@
 # Deployment
 
 
-## Introduction
+## Overview
 At some point you want to deploy your Supercharge application to production. You want to serve your application as best as possible to your audience when going live. This documentation page will point you to different deployment ideas.
 
 

directory-structure.md

@@ -1,7 +1,7 @@
 # Directory Structure
 
 
-## Introduction
+## Overview
 Supercharge gives you a default directory structure that should work well for small and large applications. The Supercharge framework tightly integrates with the given application structure by loading files from directories in your `app` folder.
 
 Of course, you’re free to modify the application structure. Make sure to update the corresponding Node.js imports when renaming folders or moving files.

encryption.md

@@ -1,5 +1,5 @@
 # Encryption
 
 
-## Introduction
+## Overview
 Encryption is not yet available in Supercharge v2.

events.md

@@ -1,7 +1,7 @@
 # Events
 
 
-## Introduction
+## Overview
 Supercharge provides you a handy event dispatcher implementing a publish/subscribe model for events occuring in your application. Events are a great way to decouple logic in your application, for example from route handlers.
 
 For example, a user registers for your application and you want to send a welcome mail. The route handler shouldn’t wait for the mailer to send the mail. Instead, you can dispatch a `UserRegistered` event to kick off a listener sending the mail.

frontend-assets.md

@@ -1,7 +1,7 @@
 # Frontend Assets
 
 
-## Introduction
+## Overview
 A new Supercharge applications ships with routes to serve assets. All asset-related routes are located in the `app/routes/assets.js` file.
 
 The routes defined in the `app/routes/assets.js` file have static references to the `public` directory to serve these assets publicly. The Supercharge application boilerplate has predefined folders and files to make it as seamless as possible for you to add your public assets.

handlebars-helpers.md

@@ -1,7 +1,7 @@
 # Handlebars Helpers
 
 
-## Introduction
+## Overview
 The Supercharge frameworks ships with built-in [support for view rendering using Handebars templates](/docs/{{version}}/handlebars). Also, Supercharge provides you a handful of convenient helpers which are automatically registered when starting your application. You can use all helpers in your Handlebars templates without extra configuration.
 
 

handlebars.md

@@ -1,7 +1,7 @@
 # Handlebars
 
 
-## Introduction
+## Overview
 Supercharge uses the [Handlebars](https://handlebarsjs.com/) template rendering engine to translate your views into HTML. Handlebars is extensible by default allows you to build complex layouts. Starting from a base layout, you may add partial views to ultimately compose the final HTML.
 
 Supercharge supports Handlbars files using the `.hbs` file extension and automatically picks up all the view files located in the `resources/views` directory.

hashing.md

@@ -1,5 +1,5 @@
 # Hashing
 
 
-## Introduction
+## Overview
 Hashing is not yet available in Supercharge v2.

http-context.md

@@ -1,7 +1,7 @@
 # HTTP Context
 
 
-## Introduction
+## Overview
 The HTTP context is a request-related object holding the `request` and `response` instances. You’ve access to the HTTP context in HTTP controllers (or route handler functions), middleware, and the error handler.
 
 

http-tests.md

@@ -1,7 +1,7 @@
 # HTTP Tests
 
 
-## Introduction
+## Overview
 Supercharge’s `base-test` utility provides a convenient interface to inject HTTP requests to your application. Each injected request returns a response object for further evaluation. Injecting HTTP requests is a great way to run integration tests in your application.
 
 The following code snippet outlines a basic HTTP test:

logger.md

@@ -1,7 +1,7 @@
 # Logging
 
 
-## Introduction
+## Overview
 Logging allows you to provide transparency in your application. If you want to learn more about the processing and details of your application parts, logging is a good way. Supercharge provides a solid logger using the [Winston](https://github.com/winstonjs/winston) logging library.
 
 Supercharge comes with a built-in logger. The logger is configurable making it seamless for you logging to different destinations, like the console or a log file.

logger.org.md

@@ -1,7 +1,7 @@
 # Logging
 
 
-## Introduction
+## Overview
 Logging allows you to provide transparency in your application. If you want to learn more about the processing and details of your application parts, logging is a good way. Supercharge provides a solid logger using the [Winston](https://github.com/winstonjs/winston) logging library.
 
 The logging utility coming with Supercharge is configurable to make it seamless for you to log to different destinations, like the console or a log file.

mailer.md

@@ -1,5 +1,5 @@
 # Mailer
 
 
-## Introduction
+## Overview
 Mailing is not yet available in Supercharge v2.

middleware.md

@@ -1,7 +1,7 @@
 # Middleware
 
 
-## Introduction
+## Overview
 Tba.
 
 

middleware.org.md

@@ -1,7 +1,7 @@
 # Middleware
 
 
-## Introduction
+## Overview
 Middlewares are an essential mechanism in your application to filter HTTP requests. A common example is an authentication middleware letting requests proceed the request lifecycle which meet the authentication requirements. In contrast, a request that is unauthenticated will be redirected to the login screen.
 
 Based on certain conditions, requests may proceed or terminate early in the request lifecycle.

pagination.md

@@ -1,5 +1,5 @@
 # Pagination
 
 
-## Introduction
+## Overview
 Pagination is not yet available in Supercharge v2.

plugins.md

@@ -1,7 +1,7 @@
 # Plugins
 
 
-## Introduction
+## Overview
 Supercharge supports [hapi’s](https://hapijs.com/tutorials/plugins) powerful plugin system. A plugin isolates functionality into a reusable utility. A plugin provides access to the HTTP server instance. Make use of plugins if you want to extend the HTTP server.
 
 Plugins in Supercharge are located in the `app/plugins` directory. This directory already exists in a default app installation.

queues.md

@@ -1,5 +1,5 @@
 # Queues
 
 
-## Introduction
+## Overview
 Queues are not yet available in Supercharge v2.

request-lifecycle.md

@@ -1,7 +1,7 @@
 # Request Lifecycle
 
 
-## Introduction
+## Overview
 Starting a Supercharge application via the `server.js` file serves an HTTP server. This HTTP server handles web requests. Each HTTP request to your application goes through a predefined lifecycle.
 
 It’s important to understand the request lifecycle. Supercharge uses the [hapi](https://hapijs.com) Node.js framework as its HTTP layer. A benefit of using hapi: a granular request lifecycle with extension points at individual lifecycle steps.

requests.md

@@ -1,6 +1,6 @@
 # HTTP Requests
 
 
-## Introduction
+## Overview
 Tba.
 

requests.org.md

@@ -1,7 +1,7 @@
 # HTTP Requests
 
 
-## Introduction
+## Overview
 Supercharge uses the [hapi web framework](https://hapijs.com) as the core for routing and request handling. Hapi comes with a solid HTTP core and the handy feature of decorating the request object. Decorations allow you to add your own properties or functions on the `request` object.
 
 Supercharge comes with dozens of request utilities provided by the [`hapi-request-utilities`](https://github.com/futurestudio/hapi-request-utilities) package. This package is available for everyone on GitHub and NPM. Feel free to install it in your app:

responses.md

@@ -1,6 +1,6 @@
 # HTTP Responses
 
 
-## Introduction
+## Overview
 Tba.
 

routing.md

@@ -1,7 +1,7 @@
 # Routing
 
 
-## Introduction
+## Overview
 Routing is an essential part of your web applictions. Each route requires a URI and route handler. The simplest way to create a route in Supercharge is to use the `Route` facade and providing the route URI and a closure function as the route handler:
 
 ```ts

routing.org.md

@@ -1,7 +1,7 @@
 # Routing
 
 
-## Introduction
+## Overview
 Routes in Supercharge are JavaScript objects consisting of three basic elements:
 
 1. the HTTP `method`

service-container.md

@@ -1,7 +1,7 @@
 # Service Container (IoC Container)
 
 
-## Introduction
+## Overview
 Supercharge uses a service container to manage dependencies. The container allows you to register dependencies and retrieve them when needed. This setup supports dependency injection in your application. Well, dependency injection is a funky term that basically describes “injecting” dependencies into a class (or function).
 
 Injecting dependencies instead of letting classes resolve them on their own has the benefit of controlling the dependencies. Controlling dependencies is especially helpful during testing because you can inject mock objects or fake data and run assertions on them.

service-providers.md

@@ -1,7 +1,7 @@
 # Service Providers
 
 
-## Introduction
+## Overview
 Service providers are essential when bootstrapping your application. The Supercharge framework uses service providers to load core functionalities and your application should use them as well.
 
 You may ask what “bootstrapping” actually means? In the context of a Supercharge application, it means composing your application: registering services into the container, loading routes and binding controllers, loading events and binding listeners. Service providers are a central place for your application.

session.md

@@ -1,5 +1,5 @@
 # HTTP Sessions
 
 
-## Introduction
+## Overview
 Sessions are not yet available in Supercharge v2.

views.md

@@ -1,7 +1,7 @@
 # Views
 
 
-## Introduction
+## Overview
 Views separate the presentation logic from application logic and represent the web views. In your application, views are served as HTML by your server to the browser. In Supercharge, all views are located in the `resources/views` directory and its subfolders.
 
 Supercharge uses the [@hapi/vision](https://github.com/hapijs/vision) library to support template rendering. The framework is configured to use [Handlebars](/docs/{{version}}/handlebars) as the view rendering engine. Find more details on Handlebars in the linked documentation.