Version 64 (modified by 16 years ago) ( diff ) | ,
---|
Proposed features for Django 1.1
Please list any proposed features for 1.1 below, along with links to relevent tickets, django-dev discussions, etc.
ORM:
- ORM aggregation (see also this django-dev thread)
- model validation
- Manager.update_or_create (see also #3182)
- add optional FOR UPDATE clause to QuerySets
- multiple database APIs
- Cache queryset results
- Identity Map (see also DjangoSpecifications/Core/SingleInstance)
- Referencing fields in queries and updates in the ORM (possibly part of django aggregation, I know the GSOC student has worked on this)
- Make select_related work with reverse onetoones
- Allow the use of property() in fields
- Support for 'DISTINCT ON' queries with QuerySet.distinct()
- Support denormalization (#8946, see also Cal Henderson's DjangoCon talk)
- Allow database API users to specify the fields to exclude in a SELECT statement
- Day of Week filter on Date/DateTime Fields (see ticket #7672)
- Native autocommit option for Postgresql backend (see ticket #3460)
- Provide the ability to update database to reflect changes in model definitions (i.e., schema evolution) (see also Database Migrations and SchemaEvolution)
Forms and templates:
- better HTML output for form fields (see also django-html)
- Extend inclusion tag syntax to allow custom templates
- Enhanced simple-tag decorator (access to context and easy block tags) (see also django-dev thread)
- Add keyword support to simple_tag and inclusion_tag
- django.forms.SafeForm - forms with built-in CSRF protection
- Refactor django.template (see also: these django-dev threads)
- Add an append method to ErrorDict
- Add a session based form wizard (see also this django-dev thread)
Admin:
- Multiple edit arbitrary fields in the admin
- Integrate Databrowse into the admin
- Integration of django-batchadmin into core
- Switch the admin to use a url resolver and be reversable
- Improve flexibility of admin.autodiscover for custom admin sites
- ModelAdmin should allow for overriding of ForeignKey/ManyToMany options
- Add the ability to add fields to admin forms and the ability to intercept form submissions so the values of those fields could be accessed. This way admin plugins could be developed.
Serving dynamic content:
- `wsgi.file_wrapper` for large file serving (see also #2131, #7894 and http://www.python.org/dev/peps/pep-0333/#optional-platform-specific-file-handling)
- Add support for streamed content (see also #7581)
General:
- the four features that were deferred until post-1.0
- customizability of contrib.comments (see also #8630)
- Inclusion of comment-utils
- Class-Based Generic Views
- URL resolver refactor
- Object history (discussed many times in
django-dev
as well) - Integrate GSOC2008 search project
- Avoid double imports (see 8193)
- Message Passing For Anonymous Users
- Follow redirect chains on the Test Client
- Honour the REMOTE_USER provided by the server
- Disable all e-mail sending for debugging
- Make the Django testcases use transactions to rollback DB changes created in a test
- Implement Atom Publishing Protocol (and related #3569)
- Signal Connection Decorators (see #9015)
- Some form of media management for apps
- Add signals to ManyRelatedManager Access to m2m relations in model.save
- Address logging
- Create a benchmark to measure the impact changes have to code (ticket #8949)
- A preferred way of creating breadcrumbs would be nice. This would improve plugability of applications
- Multilingual support in the db. There are some projects that could be integrated into the trunk as django-multilingual.
- Decoupling authentication from calling a view
Misc:
- create a list of tickets in trac db that have a high interested people count (as if something is important to many, it should be considered):
select summary from ticket where length(cc) > 50;
Note:
See TracWiki
for help on using the wiki.