Re: Views returning data only
On Jul 15, 3:13 pm, Arien <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 15, 2008 at 7:34 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
> > On Jul 15, 1:57 pm, Arien <[EMAIL PROTECTED]> wrote:
> >> On Tue, Jul 15, 2008 at 5:36 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
>
> >> If a view picks a template and renders it using some data, the
> >> template is still free to present the data any way it likes (with some
> >> Content-Type related restrictions). But you don't have to hard-wire
> >> the template (and the implicit Content-Type) in the view. Write a
> >> view that has (optional) arguments (with sensible defaults) for the
> >> template (and the Content-Type).
>
> > Indeed I could do that, but I think my pattern is more general and
> > makes sure a view is ONLY responsible for describing what data you
> > see.
>
> That *is* its only responsibility. But the view returns some kind of
> serialization of that data with some HTTP headers, not the data
> itself. Don't read too much into the text from the FAQ.
While a view cannot (should not) know the contents of the template
used to serialize the content, loading a template named
"whatever.html" couples it to an HTML Content-type. I does not make
sense to serialize JSON data in a template named .html. I could of
course use templates named "whatever.serializing_template" and use
{% ifequal content_type "json" %}[1234,3452]{% else %}12343452{% endif %}
in my template code but I think that looks butt-ugly. Also, how do I
set the Content-type-header in a Template?
> >> Django is a *Web* framework. Views are the part of the framework that
> >> generate responses to requests and both of those necessarily use HTTP.
>
> > A response-request paradigm is hardly unique to HTTP. Yes, Django is a
> > web framework and yet, both models and templates are (naturally)
> > decoupled from HTTP. The documentation even includes a paragraph about
> > using templates in stand-alone mode!
>
> Sure, but that doesn't apply to views.
Why not?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Views returning data only
On Jul 15, 3:20 pm, "Waylan Limberg" <[EMAIL PROTECTED]> wrote: > Vicvicvic, > > I think your on to something here. However, we need to remember that > one of the great things about Django views is that they are just > python functions. You can do pretty much anything you want. So, if > someone wants to build up a complete html page in python code without > any templates, they can. It will be a maintenance headache, so it's > not recommended, but its not wrong. > > If you want to build up a library of decorators that simplify your > views (and, no doubt, speed up your work), then you are free to do so. > And if you want to share that library with others, that's even better. > In fact, if you search through djangosnippets.com, I believe you'll > find a few snippets that do some of the same things your talking > about. When I feel confident that my code is clean enough, I will absolutely share it. :) > However, I don't expect that the Django core will take on your > approach as the "preffered" way to do things. The flexibility of the > views to allow various coding styles is one of Django's greatest > strengths. You can do what works for you and I can do what works for > me. > > So keep it up. Share your work and make Django a better place for > others who like that style of coding. Just don't expect the entire > community to embrace it as the "only way". Point taken :) Nevertheless, having a decorator described above would not change anything, it would just add flexibility (in my mind). The decorator would obviously only apply to whichever views you decorate, so it only forces it behavior on the views you want to use. The talk about redefining HttpRequest etc., however, is on a considerably different level. THAT would probably not go in the core until someone says "Hey, let's bring the goodness of Django to the desktop!" and I'm not even interested in doing it myself. The thought just popped up in my head. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Views returning data only
On Jul 15, 3:05 pm, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
> Hi Victor,
>
> It sounds like your pattern works well for you, which is good.
>
> Another pattern that can be used is to have the view select off of some of
> the request attributes, and maybe even add your own test functions (such as
> "accepts()") to the request class. For example:
>
> if request.accepts('application/xhtml+xml') : template_ext = "xhtml"
> elif request.is_ajax() : template_ext = "json"
> else : template_ext = "html"
> . . .
I think that's the kind of test I'd like to have in my decorator.
Thanks for the tip :)
> If you think about the broader uses of view functions, I think you may find
> that the apparent elegance of your approach breaks down. You want the view
> functions to be agnostic of whatever output format they use, and I think
> that may be possible to achieve (although you create a little bit of
> overhead in constructing and passing variables for the template that aren't
> used for all output types). However, another purpose of view functions is
> to process input and take corresponding action. In cases like this I don't
> think you can avoid making the view functions much more intimately aware of
> the underlying format (e.g., AJAX or REST request versus vanilla HTTP
> POST). This applies to how the input is parsed, but also to the subsequent
> action that is taken: for HTTP POST you may re-display a form on validation
> error, or else return a redirect on success to view the object; but for AJAX
> you will likely emit some Javascript that updates the page, either to note
> errors or to reflect a successful update.
I've pandered this problem a bit myself. As far as input goes, I think
AJAX can use POST, but yes, it could be a problem. For output, I'm
thinking about maybe making views return something a bit more advanced
than a dictionary of data. It wouldn't be as elegant, but if I return
classes like ValidationFailedResponse(data) or
SuccessfulFormSubmitResponse(data) to the decorator (I hate naming
stuff), it can use them to generate the appropriate HttpResponse. If
the format is JSON, it should return Http200 and render a template, if
it's HTML, redirect. Not as clean, but hopefully it's cleaner than the
other options...
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Views returning data only
Maybe I should mention: Since only specially decorated views act this way, the change is completely backwards-compatible. At its current state, it does restrict how you use "internal" and "format" as capturing patterns in URLs, obviously. Also, the format-decorator checks if the view returns a HttpResponse and if so, returns that directly. This is for the sake of supporting HttpResponseRedirect. An interesting effect of this whole thing is that it decouples views from not only formatting but protocol. Further generalized, they might raise NotFound-exceptions rather than Http404. A higher level mechanism would know how we're communicating with the user and make sure the right 'language' is spoken. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Views returning data only
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.
(?Phtml|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
-~--~~~~--~~--~--~---
