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
-~----------~----~----~----~------~----~------~--~---
