Code


Version 87 (modified by mattimustang, 5 years ago) (diff)

reinstated full serialization pending *proper* discussion

Django 1.2 Features

TOC()?

This page lists features which have been proposed for development/inclusion in Django 1.2. So far no decisions have been made regarding any of these features. See Version1.2Roadmap for information on the process and definition of terms.

Major features

These are the feature proposals that represent major architectural changes for Django.

  • Admin UI Enhancements (Zain Memon's GSoC project)
  • Improved/reworked CsrfProtection (see #9977, #10816)
  • i18n improvements (Marc Garcia's GSoC project)
  • #6845 Model validation (Honza Kral's GSoC project)
  • Multi-database support (Alex Gaynor's GSoC project)
  • Add {% doctype %} and {% field %} template tags from http://github.com/simonw/django-html/
  • Add support for Signing and Signed Cookies
  • Integrate the Python standard library logging module with Django
  • Support for non-relational databases: Tokyo Cabinet/Tyrant, MongoDB, Cassandra, Google Bigtable (AppEngine, #10192), Amazon SimpleDB, CouchDB, etc
  • #17 Identity mapping in the ORM
  • #373 Multi-part primary keys
  • #6735 Class-based generic views

3rd party packages for integration

These are the external projects that have been proposed for addition to Django's core.

Features under consideration

Admin

  • #494 Option for classes on admin inlines
  • #5833 Custom FilterSpecs
  • #10871 Support for input arguments on admin actions.

Cache system

  • #11269 Improve cache_page decorator

Contrib

  • Syndication feed views: http://github.com/bfirsh/syndication-view/
  • #3011 Allow for extendable auth_user module
  • #9200 Session-based FormWizard
  • #11010 Support row-level permissions by updating the User-Object and Authbackends, to take an optional object parameter, so 3rd party Apps can implement the functionality easily.
  • #2507, #11526 LDAP authentication backend
  • #11625 Add admin actions to the CommentsAdmin

Email

  • #10355 Add support for pluggable email backends.

Forms

  • #342 Read-only form fields
  • #3512 Add "required" & "error" CSS classes to form rows in as_* methods
  • #6630 Fieldsets for newforms

ORM

  • #399 Support 8-byte integer DB-fields (bigint)
  • #1480, #2626 Store datetime values as UTC, handle them consistently regardless of RDBMS, platform and make things easier for multi-timezone applications.
  • #2443 Implement DurationFields
  • #6148 Add support for database schemas
  • #7539 Add ON DELETE and ON UPDATE support
  • #11402 exists() method on QuerySets
  • #11156 Remove unnecessary savepoints with Oracle
  • #11863 Add a method to the ORM to create Model instances from raw sql queries (useful when the orm is limiting you)

Serialization

Templates

URLs

  • Replace get_absolute_url() with methods that are more useful and have more realistic names (See also: ReplacingGetAbsoluteUrl)
  • #8896 Support for subdomains in the url patterns, to allow easy reversing (or better: to allow reversing at all ;))

Not in consideration

Small, or Just Bugs

Features proposed on this list that area just bugs to be fixed or really tiny feature additions that are not controversial in any way. They're still here for posterity, but have no real role in the feature proposal process.

  • #6903 Go back to old change_list view after saving model instance
  • #7028, #7923 Improve the usability of raw_id_fields
  • #8274 Auth views allow form override (as an example, this would allow usernames longer than 30 chars to be handled)
  • #9289 Swedish (se) localflavor
  • #9819 Complete comment moderation by documenting existing approval process
  • #10284 ModelFormSet - objects are deleted even if commit=False
  • #10476 Support database-level autocommit mode in Postgresql <= 8.1
  • #11463 Vietnamese translation
  • #11716 Fix unwrapped ValueErrors on AutoField and IntegerField (patch & tests already done!)

Rejected procedurally

These are proposed features that, as of the close date for proposals, lacked concrete proposals, proof-of-concept implementations, or details needed to start implementing.

  • Add a generic "official" way to create a REST API; so far there are quite a bunch of pluggables, with varying levels of "completeness", documentation and efficiency, and they're quite hard to choose from.
  • Make easier to mantain / deploy default settings.py by either:
    • include localsettings at the end, with the recommended approach of putting DATABASE_* settings in localsettings.py
    • or: if DEBUG: { some database settings } else: { other database settings }
  • Integrate some DVCS in django-admin.py, perhaps Mercurial or Git. This would make it easier to adopt and collaborate on Django projects. (This is stolen from Rails)
  • Show all SQL commands issued in the development server, for debugging purposes, perhaps only if DEBUG=true (another one stolen from Rails / Mongrel)
  • Extra template tags and filters (http://groups.google.com/group/django-developers/browse_thread/thread/2045a50970d6a883)
  • Make working with inline formsets easier (http://stackoverflow.com/questions/442040/pre-populate-an-inline-formset, as per James: ...the way the model formsets work just make this more trouble than it's usually worth, but with a bit of API cleanup I think it could be made extremely easy., also http://groups.google.com/group/django-developers/browse_thread/thread/f9aae709a7fda689)
  • Allow inclusion of inlines in fieldsets (admin)
  • Make profiling easy, possibly by integrating profiling into Debug Toolbar (see dcramer's fork)
  • #6460 Multilingual Content in the db

Lieutenants and Committers

The lieutenants and committers for each feature will be decided when the feature list is formalized.