Just extends your models from this One... is abstract so, it will not generate a table.
Now, in your urls.py do this:
from django.conf.urls.defaults import *
from animals.models import Dog, Cat, Bird
urlpatterns = patterns('animals.views',
url(r'^$', 'index', {},Dog._meta.app_label),
)
dog=Dog()
cat=Cat()
bird=Bird()
urlpatterns+=dog.build_generic_CRUD_urls(Dog)
urlpatterns+=cat.build_generic_CRUD_urls(Cat)
urlpatterns+=bird.build_generic_CRUD_urls(Bird)
then you can create the templates, and get the urls like this:
{{ object.get_absolute_url }} View
{{ object.get_update_url }} Edit
{{ object.get_delete_url }} Delete
{{ dummy_object.get_create_url }} Create
dummy_object is a quick and dirty solution until I find some better...
With all these you can create 54 functional and low detail CRUDS in one hour. :D
Enjoy!
Sample jQuery javascript to use this view:
$(function(){
$("#id_username, #id_password, #id_password2, #id_email").blur(function(){
var url = "/ajax/validate-registration-form/?field=" + this.name;
var field = this.name;
$.ajax({
url: url, data: $("#registration_form").serialize(),
type: "post", dataType: "json",
success: function (response){
if(response.valid)
{
$("#"+field+"_errors").html("Sounds good");
}
else
{
$("#"+field+"_errors").html(response.errors);
}
}
});
});
});
For each field you will have to put a div/span with id like fieldname_errors where the error message will be shown.
- ajax
- javascript
- view
- generic
- jquery
- validation
- form
Long story short:
* Django lets you call functions in templates, but you can't pass any parameters.
* Sometimes you need to use the request object to perform certain tasks, such as determining whether the current user has permission to do something.
* The recommended approach is to call functions that require parameters in the view, and then pass the results as variables in the context. This sometimes feels a bit overkill.
* Creating a templatetag to call any function with any parameter will definitely break the intention for not letting functions to be called with parameters in templates.
* So, what if we could tell django to inject the request into certain functions? That's what this decorator is for.
For instance, suppose you have a model:
class SomeModel(models.Model):
...
def current_user_can_do_something(self, request):
...some logic here using request...
You could use the decorator like this:
class SomeModel(models.Model):
...
@inject_request
def current_user_can_do_something(self, request=None):
...some logic here using request...
And in the template go straight to:
{{ somemodel_instance.current_user_can_do_something }}
So that the decorator would perform some operations to find the request in the frame tree and inject it if found. The assertions are intented to make sure things will work even if the request cannot be found, so that the coder may program defensively.
- templates
- request
- decorators
This TestSettingsManager class takes some of the pain out of making temporary changes to settings for the purposes of a unittest or doctest. It will keep track of the original settings and let you easily revert them back when you're done.
It also handles re-syncing the DB if you modify INSTALLED_APPS, which is especially handy if you have some test-only models in tests/models.py. This makes it easy to dynamically get those models synced to the DB before running your tests.
Sample doctest usage, for testing an app called "app_under_test," that has a tests/ sub-module containing a urls.py for testing URLs, a models.py with some testing models, and a templates/ directory with test templates:
>>> from test_utils import TestManager; mgr = TestManager()
>>> import os
>>> mgr.set(INSTALLED_APPS=('django.contrib.contenttypes',
... 'django.contrib.sessions',
... 'django.contrib.auth',
... 'app_under_test',
... 'app_under_test.tests'),
... ROOT_URLCONF='app_under_test.tests.urls',
... TEMPLATE_DIRS=(os.path.join(os.path.dirname(__file__),
... 'templates'),))
...do your doctests...
>>> mgr.revert()