New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of output formatter seems to affect required parameters #156
Comments
Hi @horvathcom, The reason for the error is because your specifying you want to output the data in an svg_xml_image format, then the data your passing to that format is:
which the SVG output format can not handle by default, thus the confusion. To show why this makes sense, lets say your output_format was html, and the fields represented a form, clearly you would want the response still to be returned in an HTML output format, even though the function returns a dictionary of errors. Here is how to get around that with the current version of hug (1.9.9): Change the output format on error:
In hug 2.0.0 you will be able to do the following - 1 Transform errors to an SVG compatible format:
2 Change the output format just for the case an error occurs
3 Use smart redirects
|
Let me know if this makes sense and if you have any input into a better direction to use for this feature. Thanks! ~Timothy |
Option 3 works for me. As for the right solution, in the spirit of being as simple as possible but no simpler, I would have expected the error to be handled without being specified... in other words, where you have this above ... output_invalid=hug.output.format.json ... I would have only expected an output_invalid parameter if it did something different then the default. Said another way, the output formatter would only have come into affect if there were no exceptions raised. Having said that, I am so new to hug, I am not sure I have a sense of what it should be. What I do know is that this is a very cool piece of work. We have lots of APIs that we are using RAML to define... if this thing had RAML for the documentation output, it would be unbelievable! I love the self-documentation feature, but we also provide RAML to an API gateway. |
Hi @horvathcom, I agree with your sentiment and I'll be updating hug in the 2.0.0 release so that your initial API would have worked as you expected - you are correct that it should according to hug's defined mission statement. I've added an issue to support RAML documentation here: #163 |
Oops, option 3 didn't work for me. It still sends back content-type: application/json when there aren't errors. |
This is the closest I can get... @hug.format.content_type('image/svg+xml') @hug.get('/qrcode') ` |
Hi @horvathcom, option #2 only works on the development branch that is forming hug 2.0.0 For hug 1.9.9, the option listed above the enumerated list is the correct way to go:
you can then reuse your output image formatter as needed. Hope this is helpful. Thanks! ~Timothy |
Sorry, I really appreciate the time you are taking, but it isn't making sense to me still.... Is "if isinstance(content, dict) and 'errors' in content:" meant to be a hint to me for what to do in an exception handler? Or is content a variable with magic meaning like response and request. The qrcode modules all seem to want to force you to write to a file or io stream. It isn't clear to me how that translates into output formatters. I was thinking of just doing this one in bottle since it is the only one I have with non-JSON content, but I can't figure out basic stuff for error handling. I am wondering if I need some basic falcon knowledge? |
Hi @horvathcom, No worries! I'm always glad to help. Here is the total code sample that should work unedited to do what you want to accomplish, assuming you have the qrcode library installed:
Again, in this example you can reuse the qr_image handler anywhere you need to return a qr image. For your first question, I was rushing to provide an answer and didn't test my code, no magic involved there just was mislabeled the variable ~Timothy |
And to answer your second question, output handlers sole job is essentially to turn the data returned by your function (get_qrcode_endpoint_for_user) into a bytes object and or stream as these are the objects that the wsgi spec behind all Python Web Frameworks allows for. In addition to this it has a secondary goal of attaching a content type to the response: so a hug output formatting function always looks like
I hope this makes sense. ~Timothy |
I don't know why the presence of an output formatter would affect making sure required parameters are present...
The text was updated successfully, but these errors were encountered: