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: Some Product>, <Product: Another Product>] >>> Product.objects.filter(name__startswith='S') [<Product: Some Product>] 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') [<Product: Some Product>, <Product: Sebastian's Product>] 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 * Documentation * Documentation * Documentation / although this is planned to be done in parallel with the other phases Additional Information About Me ------------------------------- I am Sebastian Hillig, situated in Berlin, Germany. Being 21 years old, I recently finished my civil service and study IT Systems Engineering at the Hasso Plattner Institute now, where I have finished the first term these days. My background: Right after finishing grammar school, I did a 5 month internship at a local web development business, where I am currently employed for part time work on their content management system. This would be my first real involvement into open source development, so I'd be glad to be given the opportunity to participate in the highly interesting field of django development. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---