On Sun, Nov 15, 2015 at 10:53 AM, Mike Orr <[email protected]> wrote: > On Sat, Nov 14, 2015 at 4:20 PM, Jonathan Vanasco <[email protected]> > wrote: >> >> On Saturday, November 14, 2015 at 8:55:33 AM UTC-5, Mike Orr wrote: >>> >>> ... but it should work with HTTPUnprocessableEntity >>> >>> I may try that with some of my responses. >> >> >> I use some custom exceptions and handling to generate the right response. I >> don't particularly like it. >> >> I think the right way to handle this would probably be to somehow extend the >> HTTPException class and Pyramid's own handling to natively support this. I >> haven't figured out a clean way of doing it though, as it would have to >> integrate a bit with how @view_config sets up renderers. > > You mean because there's only one renderer in the wrapper and it > doesn't match this case? I've come across that both with errors and > with alternate responses (e.g., where some people get different > content depending on permissions or internal state). I either just > return a complete response and let unit tests deal with it, or have a > really small view callable that delegates to other methods to build > the return dict, and test those methods. I can't think of a way around > having only a single fixed renderer in the wrapper.
Also, I'm not really bothered if the method, which normally returns a dict, instead returns a complete response with a bunch of HTML text, because I can make some judgments based on the class; e.g., it would have return a Response in this case, or HTTPNotFound in that case. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
