In the Django FAQ, we can read this about views:
>In our interpretation of MVC, the “view” describes the data that gets
>presented to the user. It’s not necessarily how the data looks, but which data
>is presented. The view describes which data you see, not how you see it. It’s
>a subtle distinction.
In my mind, "which data you see" would be equal to a context a view
returns, not the HttpResponse or the template. Why? Because rendering
a template is saying "I have this data and I want it presented the way
this template will present it". If the view is responsible for saying
that, it is at least partly responsible for telling us how we see the
data.
Rather, if a view ONLY returned a dataset, something else would be
responsible for displaying this. In more practical terms, if a view
returns a dataset, instead of a full response, another mechanism would
be wholly in charge of formatting the data. This mechanism may then
choose which template to render, or to not render a template at all,
and just pass the dataset along.
Why is this useful? For the sake of minimizing views, but provide a
rich amount of formats. The format-choice mechanism can investigate
the request (HTTP Requests come with an Accept-header) and see what
format has been requested. Looking at Accept would be the proper way
of doing it, but it might be easier to make URLs like /forums/threads.
(?P<format>html|json|xml)
HTML? Render that template. JSON? Render that template (or just
serialize the dataset). XML? RSS? You get the idea: The formatter
takes the data and tries to present it, making it a bridge between a
view and a template.
Furthermore, the same mechanism could be asked to process an
"internal" request, that is another Python function requesting the
data. Right now, I have a couple of views which return some data. But
I'm also building another view, and I want the data from one of the
first views in this one. I can either duplicate the fetching from the
first one, or I can send an "internal" request and just get the
dataset. I pick WHICH data I want and add some to it.
My current solution:
I've written a very crude decorator to demonstrate/use this in my own
projects, but I'm note sure if posting code looks any good on Google
Groups. Summarized:
My decorated views return their dataset as a dictionary.
The decorator takes two parameters: template and formats. template is
the usual path to a template, but without an extension. formats is a
tuple of formats (('html','json')) which the view is considered able
to render.
Upon calling the view, the decorator intercepts its arguments. It
looks for a format-parameter and an internal-parameter. If internal is
True, it lets the view run and just returns the resulting dictionary
to whatever called it. If not, it checks that format is in formats and
then tries to render_to_response("%s.%s" % (template, format,
returned_dict, RequestContext(request))
As I said above, the mechanism (in my case, a decorator) should
probably try to investigate what the request looks like, rather than
checking for stuff in the URL/other parameters but as I said, it's
crude. It should also return the proper Content-type.
--
Do you think I have a point? Me not being a Django developer (and not
a very seasoned Python user at all), I realize I might have
misunderstood your... philosophy :)
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
