too basic context

[AlbanMinassian]

As a new user, I find it constraining to code (each time) my own "context.rs" to start a new project. it's not intuitive.

Some basic methods in BasicContext should be proposed by default which allow to define headers (add, del) and define the return code (404)

• add_header("headerKey", "value")
• set_status_code(418)

Thanks Ami44

[trezm]

I agree. I think, in general, BasicContext should provide a relatively generic but capable experience for those getting started. As such, I believe the methods should be:

fn set_header(key: &str, val: &str);
fn remove_header(key: &str);
fn set_status_code(code: u32, message: &str);

[AlbanMinassian]

why not

koa or express methods

• res.set(field, value) koa or express
• res.append(field , value) koa or express
• res.remove(field) koa - not found express

beware

res.status(code) koa or express - is not necessary to pass second string params

ami44

[trezm]

I have a few questions;

• What is the functional difference for the developer between set and append?
• Is there a reason to exactly align with koa and express on names? I find that a slightly more detailed name is very informative, especially as the context object becomes large.
• There's actually a builtin struct where we could build out more status codes (right now it only has ok and custom,) do you think that's easier than passing a blank string? Personally, I dislike having to use in an extra enum, but requiring the existing enum is likely more ergonomic to Rust.

On Mon, Sep 10, 2018 at 9:28 AM Ami44 notifications@github.com wrote:

why not

koa or express methods

• res.set(field, value) koa https://github.com/koajs/koa/blob/master/docs/api/response.md#responsesetfield-value or express http://expressjs.com/fr/api.html#res.set
• res.append(field , value) koa https://github.com/koajs/koa/blob/master/docs/api/response.md#responseappendfield-value or express http://expressjs.com/fr/api.html#res.append
• res.remove(field) koa https://github.com/koajs/koa/blob/master/docs/api/response.md#responseremovefield
• not found express

beware

res.status(code) koa https://github.com/koajs/koa/blob/master/docs/api/response.md#responsestatus or express http://expressjs.com/fr/api.html#res.status - is not necessary to pass second string params

ami44

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/trezm/Thruster/issues/70#issuecomment-419911613, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNnLRQmoqQR6WITVWjK6GhJI9oyfU8lks5uZmjkgaJpZM4WhVN_ .

[AlbanMinassian]

Q1: Is there a reason to exactly align with koa and express on names? R1: for reasons of consistency "Based on frameworks like Koa, and Express" at front page https://github.com/trezm/Thruster#intuitive and for marketing reasons: to attract more koa or express developers to thruster because they will quickly find the same methods (et get more stars than actix-web :-))

Q2: What is the functional difference for the developer between set and append? R2: I think "set" should overwrite the previous value if key exists, otherwise call append

Q3: do you think that's easier than passing a blank string R3: no idea! see my response R1

Ami44

[trezm]

Hmm, valid points all around. I guess since this isn't like it lives in the trait, it would be worth going through the koa and/or express libraries and just copying over a bunch of methods to the BasicContext.

For set vs. append, I think we'll only support set for simplicity's sake. My guess is that append will actually create a comma separated list of values in Koa or Express, but we can leave that for a later exercise :). I'll mark this as an improvement for dev!

To reiterate, we'll include:

fn set(key: &str, val: &str);
fn remove(key: &str);
fn status(code: u32);