Rocket/lib/src/lib.rs

#![feature(question_mark)]
#![feature(specialization)]

extern crate term_painter;
extern crate hyper;
extern crate url;
extern crate mime;
#[macro_use] extern crate log;

#[macro_use]
pub mod logger;
pub mod form;
pub mod request;
pub mod response;
pub mod content_type;

mod method;
mod error;
mod param;
mod router;
mod rocket;
mod codegen;
mod catcher;

pub mod handler {
    use super::{Request, Response};

    pub type Handler = for<'r> fn(Request<'r>) -> Response<'r>;
}

pub use logger::RocketLogger;
pub use content_type::ContentType;
pub use codegen::{StaticRouteInfo, StaticCatchInfo};
pub use request::Request;
pub use method::Method;
pub use response::{Response, Responder};
pub use error::{Error, RoutingError};
pub use param::FromParam;
pub use router::{Router, Route};
pub use catcher::Catcher;
pub use rocket::Rocket;
pub use handler::Handler;
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
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;`
			`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
Major refactoring. Merged two `Route` structure. Created `URI` and `URIBuf`. 2016-04-02 07:51:40 +00:00			`pub mod handler {`
			`use super::{Request, Response};`

HRTB for the win! Manual routes example fully working. 2016-04-03 10:36:30 +00:00			`pub type Handler = for<'r> fn(Request<'r>) -> Response<'r>;`
Major refactoring. Merged two `Route` structure. Created `URI` and `URIBuf`. 2016-04-02 07:51:40 +00:00			`}`

Use log crate for cleaner, more flexible logging. 2016-08-24 08:30:09 +00:00			`pub use logger::RocketLogger;`
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};`
Progress on errors. Started Todo example. The error function now takes in a "RoutingError" structure. The idea is that the structure includes all of the information necessary for a user to processor the error as they wish. This interface is very incomplete and may change. At a minimum, the error structure should include: 1) The request that failed. 2) Why the request failed. 3) The chain of attempted route matches, if any. 4) Something else? 2016-07-16 04:09:08 +00:00			`pub use error::{Error, RoutingError};`
Somewhat good infrastructure for params and responses. Can actually return strings and what-not from a route. Yay! 2016-03-17 08:57:04 +00:00			`pub use param::FromParam;`
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 refactoring. Merged two `Route` structure. Created `URI` and `URIBuf`. 2016-04-02 07:51:40 +00:00			`pub use handler::Handler;`