Hi Russel, > Returning HTTPResponse also provides a data formatting constraint that > your approach doesn't have. At each level of Django view, you know > you're going to get a HTTP Response.
Yes, now it makes sense the view working only with HTTP request and responses and the decorators will only work with some kind of specific information that will not be the same for each decorator. Being strict, the view (the decorated function) will always return an HTTP response, but in another (more abstract) layer... I think I'll need to find some balance in this technique. Hi Javier, > for example, make a (generic) view that simply calls a data gathering > function (which is not a view) and hands the result to a HTML > template, and another (generic) view that calls the same function but > returns a different (XML? JSON? Pickle?) representation. I don't know if I understand what you're saying but the decorator approach is working exactly like that but instead of calling these generic views, I decorate my view with it. Could you explain me that with a simple snippet? Regards, Bernardo On Dec 13, 12:14 pm, Javier Guerra Giraldez <jav...@guerrag.com> wrote: > hi, > > Russel explained the real reasons of why your proposal doesn't fit so > good in Django. > > still, this snippet: > > On Mon, Dec 12, 2011 at 7:49 PM, Bernardo <jbv...@gmail.com> wrote: > > - The framework, within reason, should deduce as much as > > possible from as little as possible. > > That last phrase tells everything I'm trying to explain. > > for me, is opposed to the "explicit is better than implicit" in the > Zen of Python. not a bad thing on itself, but something to be careful > about. (and, personally, it's a big part of why i like Django so > much better than RoR) > > now, thinking a little more on what seems to be good: separating the > 'data gathering' part of a view from the presentation part, I think it > should be handled at a slightly different level. > > for example, make a (generic) view that simply calls a data gathering > function (which is not a view) and hands the result to a HTML > template, and another (generic) view that calls the same function but > returns a different (XML? JSON? Pickle?) representation. > > paired with a middleware and some shortcuts in the urls.py, you can > have nicely separated concerns and DRYness. > > -- > Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
