On Tue, Dec 13, 2011 at 8:49 AM, Bernardo <jbv...@gmail.com> wrote:
> One thing the project I was working had and I liked was lots of
> decorators on top of controllers (what you people call views - and
> makes sense)
> Something like that:
>
> #-----------------------------
>
> @require_permission('login')
> @expose_xhr('admin/data/index.html', 'admin/data/table.html')
> @paginate('media', items=20)
> @observable(events.Admin.DataController.index)
> def index(self, page=1, search=None, filter=None):
> """
> Home page for ... bla bla
> """
> filter = Person.query.options(orm.undefer('comment_count'))
> tag = ....
>
> return {
> 'base': self.info,
> 'search': search,
> 'search_form': search_form,
> 'media_filter': filter,
> 'tag': tag,
> }
>
> #-----------------------------
>
> It feels right to make the controller returns only the data to be
> rendered/serialized instead of a HTTP response. Not doing that makes
> it a lot aware of things it shouldn't be and make it easy to repeat
> code.
Hi Bernardo,
You're not the first person I've seen suggest this approach, and it's
certainly legal Python -- but to me, it feels completely wrong.
Django's contract for a view is simple, and very closely aligned to
it's end purpose -- serving HTTP content. A Django view:
* Accepts a HTTP Request, along with any pre-parsed URL arguments
* Returns a HTTP Response
And that's it. While I can see the appeal of trying to do a classical
MVC "Controller" separation, it just doesn't seem appropriate when
you're dealing with a framework that is 100% focussed on delivering a
very specific type of output.
Having views that return HttpResponse doesn't mean you *can't* perform
good separation of concerns. A well designed view *will* separate the
rendering from the data. It just does it with normal, well-decoupled
functions.
It also doesn't mean that you must return a fully serialized HTTP
Response. Consider the case of TemplateResponse. This is a data
structure that will *eventually* be a fully rendered HTTP response,
but until it is baked, it's just a collection of data. This means your
decorator and middleware stack has ample opportunity to modify the
response before it is served to the client.
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. That means there are certain
predictable fields, structures and so on. If you have a view that
returns "Data" -- what format is that data in? Will that format change
if it's decorated? If so, what will it change into? If I have some
extra functionality that I want to add to your view, how do I build a
decorator so that I know it will always work with your view?
So -- in summary: Nobody will can stop you from taking this sort of
"return data then decorate" approach. You certainly *can* build a
fully functional Django stack that uses this approach. However, I
would personally advise against it.
Yours,
Russ Magee %-)
--
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.
