Changes between Initial Version and Version 1 of Ticket #24619


Ignore:
Timestamp:
Apr 10, 2015, 6:19:23 AM (9 years ago)
Author:
Tim Graham
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #24619

    • Property Triage Stage Unreviewed → Accepted
    • Property Type Uncategorized → New feature

  • Ticket #24619 – Description

    initial v1  
    44As a developer who is creating views/services non HTML-related (JSON, XML, etc as a response) I have huge problems with reading output from technical responses when error occurs. I'm getting in my console or shell HTML mixed with Javascript and CSS, which is hard to read. Text output from technical responses is hard-readable too, but better than HTML.
    55
    6 Technical responses should use some sort of output renderers registry based on `Accept` header. They should implement or use content type negotiation strategy and match against available renderers. Current HTML and text output can be mapped for `text/html` and `text/plain` types respectively. Also as a developer I need to extend registry of supported content types for my specific needs. For example - I need error 500 technical response returned as `application/json` content-type. Django can provide some builtin technical output renderes.
     6Technical responses should use some sort of output renderers registry based on `Accept` header. They should implement or use content type negotiation strategy and match against available renderers. Current HTML and text output can be mapped for `text/html` and `text/plain` types respectively. Also as a developer I need to extend registry of supported content types for my specific needs. For example - I need error 500 technical response returned as `application/json` content-type. Django can provide some built-in technical output renderers.
    77
    88Optionally content-type negotiation functionality can be built as a standalone helper for common use.
    … …  
    1111
    1212Extracted from #24610
    13 
Back to Top