Using Django REST with TemplateResponder for html requests
Michael Nelson
I noticed that there's an a TemplateResponder that can be used to
process web/html requests (as opposed to api requests with json/xml
etc.). But I've found I've had to modify it to use it effectively for
two reasons:
1) TemplateResponder seems to still be using form_for_model (pre 1.0)
rather than ModelForm - guessing this is just because no one has had
time yet to updated it... happy to help if no one else has it on the
cards yet (guessing it needs dynamic class creation using ModelForm as
at http://groups.google.com/group/django-users/browse_thread/thread/7ef532fa113e78d9/0442e4d3b649b987#0442e4d3b649b987
). Actually, after checking the svn log, it seems that alaasalman
intended to do this with r79, but form_for_model is still there in the
create_form method?
2) More importantly to me, the create method of the ModelResource does
not actually redirect to the resource after creation, but instead
responds with a 201 Created and the content of the newly created item
(which is effectively the same as requesting the new item itself /item/
3/, just without the redirect.) This is great for api's, and I think
probably more correct in terms of REST implementation, but not so good
for users (when using rest api with TemplateResponder) who like to
click on the 'Reload' button (which, without the redirect, re-posts
the data).
I'm asking, because I think it could be incredibly useful to people to
use the rest api generally together with the TemplateResponder for
normal non-api web app development - similar to what Rails does with
'resource' routes.
But I am not sure whether I should just quietly inherit from the
ModelResource and continue, or whether it is worthwhile discussing
modifying django_rest_api to redirect after create, so that xml/json
and html responses can all be handled in the same way (so that, like
Rails, the rest api could be used as a norm for user-submitted data as
well as xml/json apis)?
Cheers,
Michael
Alaa Salman
> 1) TemplateResponder seems to still be using form_for_model (pre 1.0)
> rather than ModelForm - guessing this is just because no one has had
> time yet to updated it... happy to help if no one else has it on the
> cards yet (guessing it needs dynamic class creation using ModelForm as
> at http://groups.google.com/group/django-users/browse_thread/thread/7ef532fa113e78d9/0442e4d3b649b987#0442e4d3b649b987
> ). Actually, after checking the svn log, it seems that alaasalman
> intended to do this with r79, but form_for_model is still there in the
> create_form method?
>
Can you please create a new issue for that. As well as some minimal code
to show the problem if possible.
> 2) More importantly to me, the create method of the ModelResource does
> not actually redirect to the resource after creation, but instead
> responds with a 201 Created and the content of the newly created item
> (which is effectively the same as requesting the new item itself /item/
> 3/, just without the redirect.) This is great for api's, and I think
> probably more correct in terms of REST implementation, but not so good
> for users (when using rest api with TemplateResponder) who like to
> click on the 'Reload' button (which, without the redirect, re-posts
> the data).
>
>
I don't know about that. Redirection is the client's responsibility not
the api. But feel free to present your case and we'll see where the
discussion goes.
> But I am not sure whether I should just quietly inherit from the
> ModelResource and continue, or whether it is worthwhile discussing
> modifying django_rest_api to redirect after create, so that xml/json
> and html responses can all be handled in the same way (so that, like
> Rails, the rest api could be used as a norm for user-submitted data as
> well as xml/json apis)?
>
I'd say go ahead and inherit. It is the usual practice when you want to
do something specific.
--
Regards,
Alaa Salman
Entrepreneur, Contractor, Programmer
http://www.codedemigod.com
Free Software Foundation Associate Member #6304
"One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man." ---Elbert Hubbard
"Never measure the height of a mountain until you have reached the top. Then you will see how low it was." ---Dag Hammarskjold