On Sat, Oct 17, 2009 at 5:15 AM, Sean Brant <brant.s...@gmail.com> wrote: > > Using a decorator allows you to do cool things like > > @provides_html('myapp/mypage.html') > @provides_json(optional_serialize_callback_can_go_here) > def my_view(request): > return {'foo': 'bar') > > Then your provides_* could check the accept-header and know how to > response. Html renders a template and json would serialize the dict. > > With that said this probably falls into the domain specific use case > and is probably not needed by enough people to be added to core, > however doing ajax apps are a breeze.
I certainly acknowledge the use case that you (and Justin) have raised here, and I'm sure you're making good use of this pattern in your own projects. However, I'm slightly hesitant to support adding this approach to core. In particular, I'm a little bit nervous about the pseudo change to the view contract. Django has always strictly enforced the 'view returns a response' contract. Moving to the use of a decorator like this means that a view's contract becomes "... or you can return a context, as long as you're decorated the right way". The best way to highlight my problem with this change is to consider the edge case where the list of decorators provided doesn't capture the context. You mention using a decorator list like: @provides_html('myapp/mypage.html') @provides_json(optional_serialize_callback_can_go_here) How do you guarantee that this stack *always* returns a response? If I leave off the provides_html decorator, who is responsible for catching the fact that the HTML case hasn't been handled? This is why I'm more in favour of Simon's TemplateResponse. The general problem you are trying to solve can also be solved, but without the change to the view contract. Using TemplateResponse (or any 'lazy' payload evaluation approach) means that a view is still required to return some sort of response. The TemplateResponse provides a guaranteed fallback - the default rendering of the TemplateResponse that the view has created. However, that response can be manipulated further up the chain - by a decorator, or a wrapper view, or a middleware, or anything else that can insert itself into the dispatch cycle. The one thing we will need to keep in mind is your use case of using a serialization callback rather than a template for rendering, but I suspect that's more of a naming issue than a technical problem. There's no reason that the render() function for a JSON handled request couldn't call a serializer (or any other callback), rather than invoking a template renderer. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---