Re: GSoC 2007 Status Update VI: Django REST interface
2007/8/12, Andreas Stuhlmüller <[EMAIL PROTECTED]>:
>
> On 8/11/07, David Larlet <[EMAIL PROTECTED]> wrote:
> > Here is my suggestion: the current forms from model or instance are
> > great but you often need a custom form, what about an extra-argument
> > to the collection (better because I already need a form in the
> > collection in order to return a creation form on the list view, about
> > that if you have better idea...) or the responder with the form class?
>
> Forms seem to be relevant only if you use TemplateResponder, therefore
> I am against adding form-specific code to ModelResource. You can
> already specify extra_context for TemplateResponder. Might that be
> sufficient?
In fact, the problem is that you use ResourceForm in model_resource
and it could be interesting to use the given form_class instead.
That's why I'm more interested in a resource argument.
About extra_content, when I'd like to give a form_class, I get an
instance in my dict which is not what I expected (I just want the
class). Maybe I haven't done the right thing? Can you put an example
of the use of extra_content to give a form class to the responder?
> > About urls, how can I get a "reversed url". For example, is it planned
> > to deal with {% url %} tag and permalink? I've tried to do this
> > without any success.
>
> This should definitely be possible, but I have not found an elegant
> way to do this yet.
Ok, thanks for your answer. My main concern is about the possibility.
Regards,
David
--~--~-~--~~~---~--~~
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: GSoC 2007 Status Update VI: Django REST interface
On Sun, 2007-08-12 at 13:28 +0200, Andreas Stuhlmüller wrote: [...] > Once the SoC final evaluation is over (Mon, August 20th), it will be a > lot easier (=possible) for me to work together with other people and > to accept code contributions. This strikes me a little strange since > SoC is supposed to encourage work within the open source community but > what you end up with is "work on your own, supported by your mentor" > (which, admittedly, works quite well). What they (Google) want to ensure is that the *code* you write is pretty much all your own work. Students are obviously strongly encouraged to participate in mailing discussions to come up with design, get feedback, fix bugs, pilfer ideas from other people, etc. Non-trivial code contributions are a bit tricky because it makes it hard to tell, at the end of the "summer" what was the students work and what was other peoples' contribution. That being said, bug fixes, etc, are almost certainly going to be fine. Particularly at this late stage, since you (Andreas) have already written a large body of work. Regards, Malcolm -- The early bird may get the worm, but the second mouse gets the cheese. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: GSoC 2007 Status Update VI: Django REST interface
On 8/11/07, David Larlet <[EMAIL PROTECTED]> wrote:
> Here is my suggestion: the current forms from model or instance are
> great but you often need a custom form, what about an extra-argument
> to the collection (better because I already need a form in the
> collection in order to return a creation form on the list view, about
> that if you have better idea...) or the responder with the form class?
Forms seem to be relevant only if you use TemplateResponder, therefore
I am against adding form-specific code to ModelResource. You can
already specify extra_context for TemplateResponder. Might that be
sufficient?
> * in order to be consistent with template, the name should be related
> to elem._meta.module_name and not self.template_object_name
Fixed, thanks.
> About urls, how can I get a "reversed url". For example, is it planned
> to deal with {% url %} tag and permalink? I've tried to do this
> without any success.
This should definitely be possible, but I have not found an elegant
way to do this yet.
> So thank you for your awesome work and I will not hesitate to fill
> a bug (and maybe to help if GSoC allow that) if I find one.
Once the SoC final evaluation is over (Mon, August 20th), it will be a
lot easier (=possible) for me to work together with other people and
to accept code contributions. This strikes me a little strange since
SoC is supposed to encourage work within the open source community but
what you end up with is "work on your own, supported by your mentor"
(which, admittedly, works quite well).
Regards,
Andreas Stuhlmüller
--~--~-~--~~~---~--~~
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: GSoC 2007 Status Update VI: Django REST interface
On 8/6/07, David Larlet <[EMAIL PROTECTED]> wrote: > * What about additional pages like: create form, update form, delete > confirmation and so on? I've just noticed the get_create_form at the > end of the TemplateResponder but how can I redirect to this function? > (I haven't seen how to do this in url generation.) > * How can I deal with custom forms for a resource? I extended the template example to include a create form and an update form [1]. Note that you need something like HttpMethodsMiddleware [2] in order to use the update form and that the forms are currently not redisplayed after erroneous input. For any other forms and extensions, just write views and add the URLs to urlpatterns (above the catch-all resource URLs). If you feel that the REST interface should support this kind of work and have ideas how this might look like, please let me know. > * Is it possible to specify the format at the end of an url or will it > break the parsing? Yes, this is possible if you specify the urlpatterns for collection and entry individually. I just added such an example [3]. > And last but not least, what is the current stability? If you can, wait at least until Fri, August 24th before using the REST interface in any kind of production environment. By then I hope to have done more thorough testing. If you stumble upon a bug, please let me know. Thanks for your feedback. Regards, Andreas Stuhlmüller [1] http://django-rest-interface.googlecode.com/svn/trunk/django_restapi_tests/examples/template.py [2] http://www.djangosnippets.org/snippets/174/ [3] http://django-rest-interface.googlecode.com/svn/trunk/django_restapi_tests/examples/fixedend_urls.py --~--~-~--~~~---~--~~ 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: GSoC 2007 Status Update VI: Django REST interface
2007/8/5, Andreas Stuhlmüller <[EMAIL PROTECTED]>: > > I am currently reading "RESTful Web Services" by Leonard Richardson > and Sam Ruby. See [3] for a summary of the main points from the > chapter on best practices for REST-oriented architectures with short > notes on where the REST interface still needs improvement. Really interesting summary, thanks for this work. > > If you feel that there are important issues I am missing, please write > me or just open a ticket [4]. Here are some random thoughts: * What about additional pages like: create form, update form, delete confirmation and so on? I've just noticed the get_create_form at the end of the TemplateResponder but how can I redirect to this function? (I haven't seen how to do this in url generation.) * How can I deal with custom forms for a resource? * Is it possible to specify the format at the end of an url or will it break the parsing? And last but not least, what is the current stability? I need to use this kind of library now and even if I develop my own last week which fits my needs, I hope this one will replace it soon because I don't want to break all my code once this project is merged to the trunk. Regards, David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC 2007 Status Update VI: Django REST interface
This is the sixth status update for my Summer of Code project. You can find more information as well as an updated timetable at [1]. During the last two weeks, I mainly worked on unit tests and on simplifying the relationship between the REST interface and URLs. I added manage.py, settings.py and tests.py in order to enable tests with Django's unit testing framework, converted the existing tests, removed the old (now obsolete) test files, added fixtures and restructured the HttpDigestAuthentication code in order to allow testing without a web server and httplib2. You now need to specify the URLs for collections and entries within urlpatterns. This change is backwards-incompatible. See the five examples [2] which replace the large urls.py example for more information on how to use the interface. The URL generation logic now uses reverse(). The class for collection entries can be specified in the Collection() constructor call. Thanks to David Larlet for recommending the the __call__ trick as a replacement for the dispatch() methods. I am currently reading "RESTful Web Services" by Leonard Richardson and Sam Ruby. See [3] for a summary of the main points from the chapter on best practices for REST-oriented architectures with short notes on where the REST interface still needs improvement. If you feel that there are important issues I am missing, please write me or just open a ticket [4]. Regards, Andreas Stuhlmüller [1] http://code.google.com/p/django-rest-interface/ [2] http://django-rest-interface.googlecode.com/svn/trunk/django_restapi_tests/examples/ [3] http://code.google.com/p/django-rest-interface/wiki/BestPractices [4] http://code.google.com/p/django-rest-interface/issues/list --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
