Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

added some more docs, updated authors

  • Loading branch information...
commit 060aff2a2960a744aadc29bba2bbd3bc7ef9968b 1 parent 6322863
@montylounge authored
View
1  AUTHORS
@@ -2,7 +2,6 @@ Primary authors:
* Kevin Fricovsky <montylounge>
-
Contributors:
* Michael Newman <newmaniese> for his patch resolving an AttributeError exception.
View
42 README.textile
@@ -4,48 +4,6 @@ h1. Introduction
A reusable Django application to create a proxy object for your models.
Intended to aggregate various content types into a model for reuse.
-What django-proxy provides is an aggregation of different content types by
-denormalizing fields on various models into one database table (using signals
-to update/delete changes to those denormalized fields). This concept was
-initially used on my old blog (howiworkdaily.com) and a hacked version in the
-TWiD (thisweekindjango) "everything" feed. I like to say this is a poor man's
-"django-tumbleweed":http://github.com/mcroydon/django-tumbleweed, which defines itself as "A framework for creating
-tumblelog views of Django models indexed by Haystack" to provide similar
-functionality. What I like about django-proxy is that the denormalized data is
-available in the database and the relationship to the source object is
-available via Generic Relation, if needed.
-
-Current implementation example:
-
-<pre>
- from django.db import models
- from django.db.models import signals
- from django_proxy.signals import proxy_save, proxy_delete
- ...
-
- class Post(models.model):
- STATUS_CHOICES = (
- (1, _('Draft')),
- (2, _('Public')),
- )
-
- title = models.CharField(max_length=150)
- body = models.TextField()
- tag_data = TagField()
- status = models.IntegerField(_('status'), choices=STATUS_CHOICES,
- default=2)
-
- class ProxyMeta:
- title = 'title'
- description = 'body'
- tags = 'tag_data'
- active = {'status':2}
-
-
- signals.post_save.connect(proxy_save, Post, True)
- signals.post_delete.connect(proxy_delete, Post)
-</pre>
-
h2. Dependencies
Nothing external. No contrib apps. Just Django proper.
View
2  django_proxy/signals.py
@@ -103,4 +103,4 @@ def proxy_delete(sender, **kwargs):
obj = model._default_manager.get(object_id=instance.id, content_type=ctype)
obj.delete()
except DoesNotExist:
- pass
+ pass
View
102 docs/Introduction.textile
@@ -0,0 +1,102 @@
+
+
+h1. Quick introduction
+
+What django-proxy provides is an aggregation of different content types by
+denormalizing fields on various models into one database table (using signals
+to update/delete changes to those denormalized fields).
+
+The ideal use case for Django-Proxy is a tumblelog or lifestream.
+
+This concept was initially used on my old blog (howiworkdaily.com) and a hacked
+version in the TWiD (thisweekindjango) "everything" feed. I like to say this
+is a poor man's "django-tumbleweed":http://github.com/mcroydon/django-tumbleweed, which defines itself as "A framework for creating
+tumblelog views of Django models indexed by Haystack" to provide similar
+functionality. What I like about django-proxy is that the denormalized data is
+available in the database and the relationship to the source object is
+available via Generic Relation, if needed.
+
+h1. Integration
+
+First you need to grab the source which is available on github's "django-proxy":http://github.com/montylounge/django-proxy project home.
+
+There are four basic steps to integrating django-proxy into your project.
+
+# add `django_proxy` to you INSTALLED__APPS settings.py
+# run `syncdb` to create the database schema (it creates one table)
+# add ProxyMeta inner class to the models you'd like to aggregate (example below)
+# wire up the signals for post_save and post_delete (example below)
+
+Let's take a quick look at the example to better understand.
+
+<pre>
+ from django.db import models
+ from django.db.models import signals
+ from django_proxy.signals import proxy_save, proxy_delete
+ ...
+
+ class Post(models.model):
+ STATUS_CHOICES = (
+ (1, _('Draft')),
+ (2, _('Public')),
+ )
+
+ title = models.CharField(max_length=150)
+ body = models.TextField()
+ tag_data = TagField()
+ status = models.IntegerField(_('status'), choices=STATUS_CHOICES,
+ default=2)
+
+ class ProxyMeta:
+ title = 'title'
+ description = 'body'
+ tags = 'tag_data'
+ active = {'status':2}
+
+
+ signals.post_save.connect(proxy_save, Post, True)
+ signals.post_delete.connect(proxy_delete, Post)
+</pre>
+
+The above is a blog Post model. What the above code allows you to do is set a ProxyMeta inner class on the model
+you'd like to aggregate and select their fields you'd like to have denormalized
+in your aggregate model. In the above example we have a Post model and we want to
+have our stream feed display the Title, Body, Tags only for posts with a active state
+of 2, meaning its Public for viewing. These values can also be callables if you
+would like, but that's up to you.
+
+Now if you also had bookmarks in this application of yours, one would assume
+that you would share a similar ProxyMeta configuration. A Bookmark normally has
+a title, a description, and tags fields. Now it may nor may not have an active state.
+Django-Proxy won't validate the active state if you don't provide it
+declaratively so you're AOK if you don't provide one.
+
+Now when you save, update, or delete models in your database wired up to Django-Proxy
+their denormalized data is maintained, along with any other content types
+that have been wired up as well.
+
+Let's take a look at what the default fixture for Proxy model from Django-Mingus looks like.
+The below is a `select` statement on the Django-Proxy database table.
+
+<pre>
+ content_type_id|object_id|title|tags
+ 36|1|Mingus - Making the complicated simple|mingus
+ 36|2|Plomer - Creativity is the power to connect.|creativity, connect
+ 36|3|Adams - Creativity is allowing yourself to make mistakes|creativity, mistakes
+ 15|1|Welcome to Mingus|django, django-mingus, blog
+ 15|2|Charles Mingus -Moanin|mingus, jazz
+ 15|3|User Based Debug your Django App|snippet, debug
+ 18|1|Django Community|django, community
+</pre>
+
+If you noticed above Django-Proxy maintains different model types in the same
+table, along with the denormalized fields. By storing the `content_type_id`
+and the `object_id` we can easily retrieve a model instance for any additional
+field look ups we need. Additionally we gain the benefit of denormalization, which
+could(should) reduce the number of queries needed to retrieve data for display
+and also, arguably, simplifies searching for data across various types if the end
+goals is aggregation. In the end it comes down to your use case and implementation,
+but Django-Proxy is designed to simplify the lifestream/tumblelog concept and
+data aggregation needs on the database level.
+
+
Please sign in to comment.
Something went wrong with that request. Please try again.