README
¶
#Revel Modules
Database
- Database A basic database module which contains a controller you can extend from to perform transactional requests
- Gorm ORM GORM object library interface
- Gorp ORM GORP object library interface
Server Engines
- Fast HTTP The Fast HTTP server engine module
- New Relic A wrapper over the Go HTTP server to record requests to https://newrelic.com/
Template Engines
Authentication
- Casbin The casbin auth module
Utility
These modules are part of the core revel and a dependency of the Revel Framework
- Static Serves static files
- Jobs The Cron Jobs runner
- TestRunner Test suite
Upcoming
- Auth A basic example of how to setup authentication
- csrf CSRF implementation
- pprof Performance profiler
- pprof Performance profiler
- GO HTTP Test Suite A new testing module which supports unit tests from the command line
Community
Learn More
Contributing
Contributors
Documentation
¶
Index ¶
Constants ¶
View Source
const ( // Version current Revel version Version = "0.21.0-dev" // BuildDate latest commit/release date BuildDate = "2018-09-23" // MinimumGoVersion minimum required Go version for Revel MinimumGoVersion = ">= go1.8" )
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
This section is empty.
Source Files
Directories
¶
| Path | Synopsis |
|---|---|
|
auth
|
|
|
basic
A basic user authentication module for Revel list of concerns: - Separating out the interface and driver - Removing DB/Storage dependency - UUID as default identifier? - how to deal with password/secret or generally, method of authorization - default {views,controllers,routes} for register/login/logut ? - reset password in most basic ? - activation (and other features) in a second / more sophisticated driver - filter for checking that user is authenticated I think a driver is made up of 2 parts data prep and data storage register and password reset are part of data prep as is the auth hash method they don't care how the data is stored then there is the data store perhaps each auth user model should instantiate 2 drivers instead of 1? one for data prep components and one for storage so the security driver and the storage driver
|
A basic user authentication module for Revel list of concerns: - Separating out the interface and driver - Removing DB/Storage dependency - UUID as default identifier? - how to deal with password/secret or generally, method of authorization - default {views,controllers,routes} for register/login/logut ? - reset password in most basic ? - activation (and other features) in a second / more sophisticated driver - filter for checking that user is authenticated I think a driver is made up of 2 parts data prep and data storage register and password reset are part of data prep as is the auth hash method they don't care how the data is stored then there is the data store perhaps each auth user model should instantiate 2 drivers instead of 1? one for data prep components and one for storage so the security driver and the storage driver |
|
app
Package db module configures a database connection for the application.
|
Package db module configures a database connection for the application. |
|
app/jobs
A job runner for executing scheduled or ad-hoc tasks asynchronously from HTTP requests.
|
A job runner for executing scheduled or ad-hoc tasks asynchronously from HTTP requests. |
|
orm
|
|
|
server-engine
|
|
|
template-engine
|
|
Click to show internal directories.
Click to hide internal directories.