rwf2
/
Rocket
mirror of https://github.com/rwf2/Rocket.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
Rocket/lib/src/lib.rs

62 lines
1.7 KiB
Rust
Raw Normal View History

Fixed all valid Clippy warnings. Removed deprecated method call.
2016-04-23 02:48:03 +00:00
#![feature(question_mark)]
Cleaned up response -> split into files. Started form example. There's something going on with Hyper. When a 303 (see other) response is sent in response to a POST, the browser does a GET to the location header. Hyper somehow misreads the method parameter here, resulting in a route failer. I need to MITM the connection to see exactly what the browser is sending and what Hyper is receiving to see who's wrong.
2016-03-28 09:34:09 +00:00
#![feature(specialization)]
Cleaned up routing code. It's nearing completion! * Should be able to write a simple O(n) router using the collision functions. * Still need to split things up into multiple files.
2016-03-19 02:05:29 +00:00
Cleanup core library documentation.
2016-09-30 04:44:27 +00:00
//! # Rocket
//!
//! Hello, and welcome to the core Rocket API documentation!
//!
//! This API documentation is highly technical and is purely a reference.
//! There's an [overview](https://rocket.rs/overview) of Rocket on the main site
//! as well as a [full, detailed guide](https://rocket.rs/guide). If you'd like
//! pointers on getting started, see the
//! [quickstart](https://rocket.rs/guide/quickstart) or [getting started
//! chapter](https://rocket.rs/guide/getting_started) of the guide.
//!
//! You may also be interested in looking at the [contrib API
//! documentation](../rocket_contrib), which contains JSON and templaring
//! support.
Routing is functional! Sort-of. Pretty console colors. Okay, so, given a URI, we can figure out which route is corresponds to. Unfortunately, the handler is not yet part of that route, and we're not parsing the parameters from the path quite yet. But, we're almost there!
2016-03-21 09:22:22 +00:00
extern crate term_painter;
Rocket is almost operational! `routes!` macro complete. Here's what works so far: * The `route` decorator checks its inputs correctly. There's a nice utility for doing this, and it's working quite well at the moment. * The `route` decorator emits a `route_fn` and a `route_struct`. The `routes` * macro prepends the path terminator with the route struct prefix. The * `Rocket` library can read mount information (though not act on it properly just yet) and launch a server using Hyper.
2016-03-12 18:45:19 +00:00
extern crate hyper;
Fully working todo example. Apparently didn't commit in a while. Need to be better at that.
2016-08-02 02:07:36 +00:00
extern crate url;
New type: ContentType. Parse ContentType from attribute.
2016-08-23 03:34:22 +00:00
extern crate mime;
Use log crate for cleaner, more flexible logging.
2016-08-24 08:30:09 +00:00
#[macro_use] extern crate log;
#[macro_use]
pub mod logger;
pub mod form;
pub mod request;
pub mod response;
Cleanup core library documentation.
2016-09-30 04:44:27 +00:00
#[doc(hidden)]
Use log crate for cleaner, more flexible logging.
2016-08-24 08:30:09 +00:00
pub mod content_type;
Rocket is almost operational! `routes!` macro complete. Here's what works so far: * The `route` decorator checks its inputs correctly. There's a nice utility for doing this, and it's working quite well at the moment. * The `route` decorator emits a `route_fn` and a `route_struct`. The `routes` * macro prepends the path terminator with the route struct prefix. The * `Rocket` library can read mount information (though not act on it properly just yet) and launch a server using Hyper.
2016-03-12 18:45:19 +00:00
Major refactoring. Here's the idea: under the `Rocket` namespace should live things critical to writing simple Rocket apps: Request, Response, Error, etc. Nothing should be nested more than one level deep. Only items required for more complex things (implementing uncommon traits, etc.) should be nested one level deep. This commit is the first attempt at realizing this.
2016-04-01 23:54:53 +00:00
mod method;
mod error;
mod param;
mod router;
mod rocket;
HRTB for the win! Manual routes example fully working.
2016-04-03 10:36:30 +00:00
mod codegen;
Progress on error handling. Calling them 'catchers' for now. Added `error` decorator and `errors` macro. The current idea is that you can have "catchers" for all valid errors code (in range [400, 500). At the moment, catchers are just request handlers, and the decorator expected an empty function signature for the error handler. Obviously, this is pretty useless. Not sure on what the API should be here. But, progress. Oh, one more thing: who should handle forwarding a request to a catcher? Probably not the router. So, the main Rocket should?
2016-04-06 10:26:43 +00:00
mod catcher;
Major refactoring. Here's the idea: under the `Rocket` namespace should live things critical to writing simple Rocket apps: Request, Response, Error, etc. Nothing should be nested more than one level deep. Only items required for more complex things (implementing uncommon traits, etc.) should be nested one level deep. This commit is the first attempt at realizing this.
2016-04-01 23:54:53 +00:00
Cleanup core library documentation.
2016-09-30 04:44:27 +00:00
#[doc(hidden)]
Major refactoring. Merged two `Route` structure. Created `URI` and `URIBuf`.
2016-04-02 07:51:40 +00:00
pub mod handler {
Major overhual: Request, ErrorHandler, ContentType.
2016-08-26 08:55:11 +00:00
use super::{Request, Response, Error};
Major refactoring. Merged two `Route` structure. Created `URI` and `URIBuf`.
2016-04-02 07:51:40 +00:00
Major overhual: Request, ErrorHandler, ContentType.
2016-08-26 08:55:11 +00:00
pub type Handler = for<'r> fn(&'r Request<'r>) -> Response<'r>;
pub type ErrorHandler = for<'r> fn(error: Error, &'r Request<'r>) -> Response<'r>;
Major refactoring. Merged two `Route` structure. Created `URI` and `URIBuf`.
2016-04-02 07:51:40 +00:00
}
Cleanup core library documentation.
2016-09-30 04:44:27 +00:00
#[doc(hidden)]
This commit is a squash of the following commits: * Add content-type responsers for JSON, HTML, and plain text. * Use content-type responders in content_type example. * Conditionally create Request `from` HypRequest. * Clean-up dispatching and handling in main rocket. * Change Level enum to Logging Level and reexport. * Allow users to set logging level before launch. * Fix content_type example error handling. * Percent decode params when user requests `String`.
2016-08-27 01:37:28 +00:00
pub use logger::{RocketLogger, LoggingLevel};
New type: ContentType. Parse ContentType from attribute.
2016-08-23 03:34:22 +00:00
pub use content_type::ContentType;
Progress on error handling. Calling them 'catchers' for now. Added `error` decorator and `errors` macro. The current idea is that you can have "catchers" for all valid errors code (in range [400, 500). At the moment, catchers are just request handlers, and the decorator expected an empty function signature for the error handler. Obviously, this is pretty useless. Not sure on what the API should be here. But, progress. Oh, one more thing: who should handle forwarding a request to a catcher? Probably not the router. So, the main Rocket should?
2016-04-06 10:26:43 +00:00
pub use codegen::{StaticRouteInfo, StaticCatchInfo};
Major refactoring. Here's the idea: under the `Rocket` namespace should live things critical to writing simple Rocket apps: Request, Response, Error, etc. Nothing should be nested more than one level deep. Only items required for more complex things (implementing uncommon traits, etc.) should be nested one level deep. This commit is the first attempt at realizing this.
2016-04-01 23:54:53 +00:00
pub use request::Request;
Rocket is almost operational! `routes!` macro complete. Here's what works so far: * The `route` decorator checks its inputs correctly. There's a nice utility for doing this, and it's working quite well at the moment. * The `route` decorator emits a `route_fn` and a `route_struct`. The `routes` * macro prepends the path terminator with the route struct prefix. The * `Rocket` library can read mount information (though not act on it properly just yet) and launch a server using Hyper.
2016-03-12 18:45:19 +00:00
pub use method::Method;
Major refactoring. Here's the idea: under the `Rocket` namespace should live things critical to writing simple Rocket apps: Request, Response, Error, etc. Nothing should be nested more than one level deep. Only items required for more complex things (implementing uncommon traits, etc.) should be nested one level deep. This commit is the first attempt at realizing this.
2016-04-01 23:54:53 +00:00
pub use response::{Response, Responder};
Major overhual: Request, ErrorHandler, ContentType.
2016-08-26 08:55:11 +00:00
pub use error::Error;
Add trailing params.
2016-09-08 07:02:17 +00:00
pub use param::{FromParam, FromSegments};
Major refactoring. Merged two `Route` structure. Created `URI` and `URIBuf`.
2016-04-02 07:51:40 +00:00
pub use router::{Router, Route};
Progress on error handling. Calling them 'catchers' for now. Added `error` decorator and `errors` macro. The current idea is that you can have "catchers" for all valid errors code (in range [400, 500). At the moment, catchers are just request handlers, and the decorator expected an empty function signature for the error handler. Obviously, this is pretty useless. Not sure on what the API should be here. But, progress. Oh, one more thing: who should handle forwarding a request to a catcher? Probably not the router. So, the main Rocket should?
2016-04-06 10:26:43 +00:00
pub use catcher::Catcher;
Major refactoring. Here's the idea: under the `Rocket` namespace should live things critical to writing simple Rocket apps: Request, Response, Error, etc. Nothing should be nested more than one level deep. Only items required for more complex things (implementing uncommon traits, etc.) should be nested one level deep. This commit is the first attempt at realizing this.
2016-04-01 23:54:53 +00:00
pub use rocket::Rocket;
Major overhual: Request, ErrorHandler, ContentType.
2016-08-26 08:55:11 +00:00
pub use handler::{Handler, ErrorHandler};