Introducing ModelView, a RESTful class-based view of your resources

[David Larlet]

Hello,

This is not a secret that I'm interested in both Django and Semantic
Web. I'm following discussion about Django+REST for more than two
years and when I realize that newforms-admin branch will use class-
based generic views [1], I decided that it's probably the right moment
to do something with that.

[1] http://code.djangoproject.com/ticket/6735

The attached code is built on top of this patch, I need to discuss
with jkocherhans in order to avoid duplicate code but consider it more
as a proof-of-concept for now, here is the (incomplete) doc:

ModelView: a RESTful class-based view of your resources
=======================================================

Philosophy
----------

The goal of this class is to provide a lightweight REST
interface, I know
that django-rest-interface exists but it's abandoned and it
suffers from
some defaults. Given my experience with it, I always need to
rewrite large
parts of the library in order to customize it to fits with my own
needs.

In order to avoid this with ModelView, the philosophy is to allow
dead-easy subclassing with granularity at each point.

Note: I totally respect what had been done before and this class is
inspired from a lot of existing projects so many thanks to all
authors.

Goals
-----

Basically, it dispatches requests to the appropriated function
given the
HTTP verb and it allows you to specify a responder in order to
avoid
duplication of code at the resource logic level.

You can specify your own responders, and restrict to allowed HTTP
methods.

Secret goal: to be honest, I dream of resource oriented stuff in
Django's trunk for years now. A RESTful Django's (newforms-)admin
could be
awesome too in order to provide a built-in API!

Example
-------

A quick example in order to demonstrate what is possible.

models.py::

class Post(models.Model):
title = models.Charfield(max_length=200)
slug = models.SlugField(max_length=200,
prepopulate_from=('title',), unique=True)
content = models.TextField()

urls.py::

blog = ModelView(Post.objects.filter(is_online=True),
responders=(HtmlResponder, JsonResponder), methods=('GET',))
blog_admin = ModelView(Post.objects.all(), methods=('GET',
'POST', 'PUT', 'DELETE'))
urlpatterns = pattern('',
url(^blog/(?P<slug>[-\w]+)/(?P<format>(html|json))?/?$),
blog, name='blog'),
url(^blog/admin/(?P<object_pk>\d)/), blog_admin,
name='blog_admin'),
)

Note: here we consider that you want a custom admin for your blog,
otherwise Django's built-in admin is much more interesting, of
course.

TODO
----

* Add tests and documentation
* Create a collection of generic Responders
* Handle receivers in order to use it as an API (for the
moment,
it assumes that you receive formencoded data), need more
reflexion.
* Handle privacy, need more reflexion
* See what can be done with APP, it could be fun!
* Ideas?

I know that it needs tests and documentation but I'd like to bring the
discussion here because I think it's important to have feedback before
going too deep. So let me know if my secret goals above are crazy or
if I need to spend more time on this.

Cheers,
David (aka david`bgk on #django-dev)

[Ivan Sagalaev]

David Larlet wrote:
> This is not a secret that I'm interested in both Django and Semantic
> Web. I'm following discussion about Django+REST for more than two
> years and when I realize that newforms-admin branch will use class-
> based generic views [1], I decided that it's probably the right moment
> to do something with that.
>
> [1] http://code.djangoproject.com/ticket/6735

David, this is a good news for us REST-fans :-). However don't you think
it could better start living as a separate app? It could get some early
adoption without needing to pursue inclusion in trunk.

> * Handle receivers in order to use it as an API (for the
> moment,
> it assumes that you receive formencoded data), need more
> reflexion.

How about registering handlers for specific mimetypes that would convert
from raw data into a python dict. ModelView will have a built-in method
for formencoded mimetype and a derived class could add its own like this:

@register_mimetype('application/atom+xml')
def atom_to_dict(self, data_stream):
# parse data_stream
return {
'attr': 'value',
}

[David Larlet]

Le 8 juin 08 à 16:11, Ivan Sagalaev a écrit :

>
> David Larlet wrote:
>> This is not a secret that I'm interested in both Django and Semantic
>> Web. I'm following discussion about Django+REST for more than two
>> years and when I realize that newforms-admin branch will use class-
>> based generic views [1], I decided that it's probably the right
>> moment
>> to do something with that.
>>
>> [1] http://code.djangoproject.com/ticket/6735
>
> David, this is a good news for us REST-fans :-). However don't you
> think
> it could better start living as a separate app? It could get some
> early
> adoption without needing to pursue inclusion in trunk.

Of course, I just want to know if it could be possible as a middle-
term goal because it doesn't involve the same energy if it's for me, a
couple of REST-fans or the trunk (for example, tests and documentation
are not exactly the same).

Anyway, I'll setup a repository and add some generic tests, that's the
minimum.

>
>> * Handle receivers in order to use it as an API (for the
>> moment,
>> it assumes that you receive formencoded data), need more
>> reflexion.
>
> How about registering handlers for specific mimetypes that would
> convert
> from raw data into a python dict. ModelView will have a built-in
> method
> for formencoded mimetype and a derived class could add its own like
> this:
>
> @register_mimetype('application/atom+xml')
> def atom_to_dict(self, data_stream):
> # parse data_stream
> return {
> 'attr': 'value',
> }

Yes, that's one of the approaches I'm thinking about, as for
permission, using decorators looks to be interesting. I need to write
some doc about that too.

Thanks for your answer,
David

[David Larlet]

Le 9 juin 08 à 13:52, David Larlet a écrit :

>
> Le 8 juin 08 à 16:11, Ivan Sagalaev a écrit :
>>
>> David Larlet wrote:
>>> This is not a secret that I'm interested in both Django and Semantic
>>> Web. I'm following discussion about Django+REST for more than two
>>> years and when I realize that newforms-admin branch will use class-
>>> based generic views [1], I decided that it's probably the right
>>> moment
>>> to do something with that.
>>>
>>> [1] http://code.djangoproject.com/ticket/6735
>>
>> David, this is a good news for us REST-fans :-). However don't you
>> think
>> it could better start living as a separate app? It could get some
>> early
>> adoption without needing to pursue inclusion in trunk.
>
> Of course, I just want to know if it could be possible as a middle-
> term goal because it doesn't involve the same energy if it's for me,
> a couple of REST-fans or the trunk (for example, tests and
> documentation are not exactly the same).
>
> Anyway, I'll setup a repository and add some generic tests, that's
> the minimum.

Here it is: http://code.larlet.fr/django-modelviews/ (at least for the
first part).
I'll setup the base architecture but feel free to participate, push
access is granted for all.

Cheers,
David

[tifosi]

Hi David,

Thank for your code and the repository, I use the django-rest-interface and
it's good news, that someone continue the job.

I would like to get nested resources (e.g.: /articles/1/comments/ or
/user/username/jobs/) and the problem is that you have to pass statically
the queryset. I think I can use a decorator but I don't know how I can do
this. Do you have a suggestion?

Regards

Clément

(Sorry for my English, I'm French)

--
View this message in context: http://www.nabble.com/Introducing-ModelView%2C-a-RESTful-class-based-view-of-your-resources-tp17718460p18009510.html
Sent from the django-developers mailing list archive at Nabble.com.

[mattim...@gmail.com]

Hi Clement,

Have a look in the django-rest-interface examples [1] they cover this
exactly. You can do what you want by sub-classing Collection.

[1] http://code.google.com/p/django-rest-interface/source/browse/trunk/django_restapi_tests/examples/custom_urls.py

regards

Matthew

On Jun 20, 12:15 am, tifosi <fossati.clem...@gmail.com> wrote:
> Hi David,
>
> Thank for your code and the repository, I use the django-rest-interface and
> it's good news, that someone continue the job.
>
> I would like to get nested resources (e.g.: /articles/1/comments/ or
> /user/username/jobs/) and the problem is that you have to pass statically
> the queryset. I think I can use a decorator but I don't know how I can do
> this. Do you have a suggestion?
>
> Regards
>
> Clément
>
> (Sorry for my English, I'm French)
>
> --

> View this message in context:http://www.nabble.com/Introducing-ModelView%2C-a-RESTful-class-based-...

[David Larlet]

Salut Clément,

Le 19 juin 08 à 16:15, tifosi a écrit :

>
> Hi David,
>
> Thank for your code and the repository, I use the django-rest-
> interface and
> it's good news, that someone continue the job.
>
> I would like to get nested resources (e.g.: /articles/1/comments/ or
> /user/username/jobs/) and the problem is that you have to pass
> statically
> the queryset. I think I can use a decorator but I don't know how I
> can do
> this. Do you have a suggestion?

I'll think about that this weekend, I have some ideas about the way to
handle that in an easy way.

>
>
> (Sorry for my English, I'm French)

Nobody is perfect ;)

Cheers,
David

ps : you can join us on #django-fr

[tifosi]

Thanks for your quick answser !
I join #django-fr and #django. Are you on these channels ?

About the solution, I subclass Collection and Entry. Perhaps we can pass the
nested Collection to the master Collection ? But we must also pass the reg
exp of nested Collection.

Bonne soirée

Clément

--
View this message in context: http://www.nabble.com/Introducing-ModelView%2C-a-RESTful-class-based-view-of-your-resources-tp17718460p18035051.html