Re: Views returning data only
Hi Victor, http://www.djangosnippets.org/snippets/821/ ? On Tue, Jul 15, 2008 at 5:36 PM, vicvicvic <[EMAIL PROTECTED]> wrote: > > 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. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 Tue, Jul 15, 2008 at 9:10 AM, vicvicvic <[EMAIL PROTECTED]> wrote: > 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: [...] > 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 %}1234 p>3452{% endif %} > > in my template code but I think that looks butt-ugly. Also, how do I > set the Content-type-header in a Template? Why not pass the template and the Content-Type to the view? See django.views.generic for examples of that approach. >> >> 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? Views are your interface to the outside world, and since Django is a Web framework that world speaks HTTP. Arien --~--~-~--~~~---~--~~ 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: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 Tue, Jul 15, 2008 at 8:20 AM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > 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. ... or any other callable. Arien --~--~-~--~~~---~--~~ 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
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. 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". On Tue, Jul 15, 2008 at 6:36 AM, vicvicvic <[EMAIL PROTECTED]> wrote: > > 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 :) > > > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to
Re: Views returning data only
On Tue, Jul 15, 2008 at 5:51 AM, vicvicvic <[EMAIL PROTECTED]> wrote: > An interesting effect of this whole thing is that it decouples views > from not only formatting but protocol. Django is a *Web* framework. Views are the part of the framework that generate responses to requests and both of those necessarily use HTTP. Arien --~--~-~--~~~---~--~~ 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 Tue, Jul 15, 2008 at 5:36 AM, vicvicvic <[EMAIL PROTECTED]> wrote: > > 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. 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). > 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. Or you could write a function that fetches and returns it, and use that function in both views. Arien --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---