Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lionel Sambuc
    @sambuc
    Hello, I have a been trying out thruster, and so far so good. I am hitting a small hitch though. I am implementing a web service, with the goal of it being more or less a drop in replacement for an other system. That systems accepts GET queries where the same parameter appears multiple times, in order to pass a list of values for that parameter.
    for example:
    var="X"&var="y"
    from the context, I can retrieve parameter with context.query_params, but as this is a hash map, var only gets one value, the last one.
    Before I go on and re-parse myself the request.path, is there a way to retrieve that as a vector or some kind of collection per parameter?
    Lionel Sambuc
    @sambuc
    Nevermind, I found the implementation of query_params, I will duplicate it and adapt it for my use-case.
    Peter Mertz
    @trezm
    hello! that's what I would suggest :) feel free to make a PR with your adapted use case as well!
    Lionel Sambuc
    @sambuc
    I'll try to come up with something clean and do so. I am still learning Rust as well.
    Peter Mertz
    @trezm
    sounds good! Let me know if you need any help, this should (hopefully) be a pretty straightforward implementation :)
    also, if I fail to respond quickly, it's because for some reason push notifications aren't working on my phone for gitter :cry:, but I'll usually see the email by the next day.
    it's not that I don't want to talk
    Lionel Sambuc
    @sambuc
    No problem at all.
    I have been on IRC as well, I don't except people to be around on call all day ;)
    Peter Mertz
    @trezm
    what a healthy attitude! love it!
    Lionel Sambuc
    @sambuc
    Well, there is one thing, to be able to hold either one String or a Vec<String> I introduced an enum like so:
    enum MultiValued<T> {
        One(T),
        Many(Vec<T>),
    }
    So that I get a HashMap<String, MultiValued<String>>, but Context.set_query_params() expects a HashMap<String, String>.
    What would be the best? Change my approach to concat somehow the multiple values in a single string, or to re-implement a whole Context?
    Lionel Sambuc
    @sambuc
    Just a quick note: a lot of links point to http://thruster.github.io, but this gives a 404 currently.
    Sayan Nandan
    @sntdevco
    @sambuc Agreed, it's really misleading
    Christopher Karper
    @CKarper
    Hello all. Is this a live channel?
    Been a while since any responses from @trezm, just figured I'd ask.
    I'm working with Thruster and trying to figure out how to handle errors gracefully. We've messed with the Try trait, adding things to the Context... Just wanted to chat about best practices, and maybe get some recommendations.
    Our ideal is to use the ? postfix in middlewares, and either have a use_middleware or another special case error handling function registered. But any solution we come up with is either very verbose, or loses the Context along the way.
    Peter Mertz
    @trezm
    My god, I'm so sorry, gitter notifications are totally broken for me clearly, I'll address the above comments just give me a few minutes here!
    Peter Mertz
    @trezm
    @sambuc I'll update those links right now
    @CKarper that's actually something that I've been trying to work through and am totally open to suggestions. My current thought was to:
    • Add a thruster-specific error that, when returned, thruster will know how to turn that into a valid error message.
    • Add an additional proc attribute (#[tryable] perhaps?) that allows the function it modifies to return a Result<Context, Thruster::Error>
      I'd love to hear y'alls thoughts on that
    Christopher Karper
    @CKarper
    I've been thinking it through, and the difficulty comes from the fact that the Context ownership is passed along through the middleware chain. And again, I'm new to Rust, but I'm wondering if we could have Thruster maintain ownership of the Context at creation, then pass a reference to the middleware chain. If so, then Errors are simply dealt with. You can have a top level middleware that handles those, or you could add a special method to App to set_error_handler or something like that.
    Peter Mertz
    @trezm
    but each function would still have to return Result<Context, Thruster::Error> yes?
    Christopher Karper
    @CKarper
    I don't know, it might bring a need for Mutexes into the mix. I'm just sort of noodling.
    I have someone at work who's way more experienced. I'll start a github issue for discussion around error chains. We can collab there if that's good.
    Peter Mertz
    @trezm
    Perfect! I should have a workable branch to reference by tomorrow as well.
    Peter Mertz
    @trezm
    thought y'all might be interested to see what happened when I migrated one of my apps to use the new error handling:
    Screen Shot 2019-06-11 at 12.18.24 PM.png