Re: GSoC proposal: Resource-based Models
On Wed, Apr 2, 2008 at 4:42 PM, David Larlet <[EMAIL PROTECTED]> wrote: > > Le 2 avr. 08 à 02:09, [EMAIL PROTECTED] a écrit : > > > > > > > Models in Django are conceputally based on tables in a database. I'd > > like to enhance that with the introduction of resource-based models. > > The basic idea comes from Ruby on Rails' ActiveResource, which allows > > for interaction between two sites through a RESTful API. I would like > > to take this a step further and provide an implementation of this type > > of interface not bound specifically to REST. The interface will be > > generic enough to allow for different types of sources. > > I couldn't be more interested in a GSoC because that's exactly what I > miss in Django. Thanks for proposing that project, I really hope it > will be accepted and count me on for extending the base with at least > RDFModel once you setup the base. I'm already dreaming of some kind of: > >class User(models.RDFModel): >user = whatever(DjangoUser.name) ># mmh, I need more time to think about the way to declare triples > >class Meta: >source = sources.FOAFSource() > Btw, RDFAlchemy provides a kind of ORMish layer. I am using it currently in one of my semweb projects though it hasnt yet reached the power of ActiveRDF. Regards Rajeev J Sebastian --~--~-~--~~~---~--~~ 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 proposal: Resource-based Models
I am also extremely interested. This is exactly what I need for a project I'm currently working on and one I may be working on for this year's SoC. Let me know if it gets accepted - I'd love to discuss it with you and I can help test. Thanks Ben On 2 Apr 2008, at 01:09, [EMAIL PROTECTED] wrote: > > Introduction of resource-based Models > = > > My name is Sebastian Hillig and I currently study IT Systems > Engineering in Potsdam/Germany at the Hasso Plattner Institute. > > I came to Django when exploring the "world" of web frameworks about > 1.5 years ago and gladly got stuck to it. Therefore I am interested in > taking part in Google Summer of Code for Django. > > The Proposal > > > Models in Django are conceputally based on tables in a database. I'd > like to enhance that with the introduction of resource-based models. > The basic idea comes from Ruby on Rails' ActiveResource, which allows > for interaction between two sites through a RESTful API. I would like > to take this a step further and provide an implementation of this type > of interface not bound specifically to REST. The interface will be > generic enough to allow for different types of sources. > > > --~--~-~--~~~---~--~~ 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 proposal: Resource-based Models
Le 2 avr. 08 à 02:09, [EMAIL PROTECTED] a écrit : > > > Models in Django are conceputally based on tables in a database. I'd > like to enhance that with the introduction of resource-based models. > The basic idea comes from Ruby on Rails' ActiveResource, which allows > for interaction between two sites through a RESTful API. I would like > to take this a step further and provide an implementation of this type > of interface not bound specifically to REST. The interface will be > generic enough to allow for different types of sources. I couldn't be more interested in a GSoC because that's exactly what I miss in Django. Thanks for proposing that project, I really hope it will be accepted and count me on for extending the base with at least RDFModel once you setup the base. I'm already dreaming of some kind of: class User(models.RDFModel): user = whatever(DjangoUser.name) # mmh, I need more time to think about the way to declare triples class Meta: source = sources.FOAFSource() Good luck! Cheers, 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 proposal: Resource-based Models
Introduction of resource-based Models = My name is Sebastian Hillig and I currently study IT Systems Engineering in Potsdam/Germany at the Hasso Plattner Institute. I came to Django when exploring the "world" of web frameworks about 1.5 years ago and gladly got stuck to it. Therefore I am interested in taking part in Google Summer of Code for Django. The Proposal Models in Django are conceputally based on tables in a database. I'd like to enhance that with the introduction of resource-based models. The basic idea comes from Ruby on Rails' ActiveResource, which allows for interaction between two sites through a RESTful API. I would like to take this a step further and provide an implementation of this type of interface not bound specifically to REST. The interface will be generic enough to allow for different types of sources. Let me explain the pieces of this system. There are models and sources. Models define the data that a source can fetch. For purposes to fit this in a short period of development, four months, I will implement the following models and sources: * RESTModel * XMLSource Here is a quick example of how this might look:: from django_resource_models import models, sources class Product(models.RESTModel): name = models.CharField() class Meta: source = sources.XMLSource("http://example.com/products/;) The model will define the fields that it wants to have access to through the source. The RESTModel will simply be an abstraction on top of XMLSource which will understand how to deal with the data given by the source. It is not entirely required to explicitly define the models in this way. One could use a call to `./manage.py inspectapi url` to introspect the API and provide the code for integration. Using the RESTModel above, one can perform similar QuerySet calls on the API:: >>> Product.objects.all() [, ] >>> Product.objects.filter(name__startswith='S') [] The implementation of this would more than likely need to be done in- memory and could result into performing less optimally than through a database. However, this approach and method is "buyer beware" in that the user will be fully understanding of what exactly this all means. Another aspect that will need to be addressed is dealing with creating data from this side:: >>> product = Product.objects.create() >>> product.name = "Sebastian's Product" >>> product.save() >>> Product.objects.filter(name__startswith='S') [, ] Another item of importance is integration with existing models:: from django_resource_models import models as resource_models class Post(models.Model): title = models.CharField(max_length=100) body = models.TextField() featured_product = resource_models.ForeignKey(Product) >>> Post.objects.filter(product__name__startswith='S') Allowing for that type of filtering may or may not be possible with the current Django code. It will be a goal to see about trying to accomplish this or if worse comes to worse it is disallowed. The primary concern of this project is to provide a framework for pluggable resources mapped to models, which are able to consume and produce other resources than database tables. It wouldn't claim to have magical powers and read the developer's mind but provide a convenient set of (optional) functionalities like caching and integration to the ORM by trying to make the developer only write as much code as is really needed. Rough Plan -- April 14th: * Announcement of accepted students Preparation phase (2-4 weeks parallel to other phases): * Dig into the Django core, get a feeling and document model- creation if not done yet, look for points to hook in. * Explore the REST-architecture * Figure out solutions for problems like: * ForeignKey integration * Resource downtimes * Making the base model as generic as possible without losing functionality. * Writing data back to resource. * Caching and cache staleness detection. * Handling resources that don't have a unique identifier. * How to provide complete integration with the ORM (without tables?) * Ideal notation to satisfy generity * Investigate the need for improvement for django-rest- interface April 26th: Coding phase 1 (~4 weeks): * Base model and base resource implementation * Basic ORM integration * Implementation of a dummy model and resource June 15th: * Start with integration of RESTModel and XMLSource * Refine integration to ORM * Caching July 7th: * MIDTERM EVALUATION July 14th: Coding phase 2 (3-6 weeks) * Writeback to resource * Refine ORM integration * Finish integration of RESTModel and XMLSource Rest of the time up to August 18th: * Experiment with different sources * Ensure good test coverage *