Django

Web framework for perfectionists with deadlines
Download

Django Ranking & Summary

Advertisement

  • Rating:
  • License:
  • BSD
  • Price:
  • FREE
  • Publisher Name:
  • Django Software Foundation
  • Publisher web site:
  • http://www.djangoproject.com/
  • Operating Systems:
  • Mac OS X
  • File Size:
  • 5.3 MB

Django Tags


Django Description

Web framework for perfectionists with deadlines Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. Django makes it easier to build Web apps more quickly and with less code.Developed and used over two years by a fast-moving online-news operation, Django was designed to handle two challenges: the intensive deadlines of a newsroom and the stringent requirements of the experienced Web developers who wrote it. It lets you build high-performing, elegant Web applications quickly.Django focuses on adhering to the DRY principle and automating as much as possible.Here are some key features of "Django":· Object-relational mapperDefine your data models entirely in Python. You get a rich, dynamic database-access API for free - but you can still write SQL if needed.· Automatic admin interfaceSave yourself the tedious work of creating interfaces for people to add and update content. Django does that automatically, and it's production-ready.· Elegant URL designDesign pretty, cruft-free URLs with no framework-specific limitations. Be as flexible as you like.· Template systemUse Django's powerful, extensible and designer-friendly template language to separate design, content and Python code.· Cache systemHook into memcached or other cache frameworks for super performance - caching is as granular as you need.· InternationalizationDjango has full support for multi-language applications, letting you specify translation strings and providing hooks for language-specific functionality. Requirements: · Python 2.3 or later What's New in This Release: ORM improvements: · Two major enhancements have been added to Django's object-relational mapper (ORM): aggregate support, and query expressions. Aggregate support: · It's now possible to run SQL aggregate queries (i.e. COUNT(), MAX(), MIN(), etc.) from within Django's ORM. You can choose to either return the results of the aggregate directly, or else annotate the objects in a QuerySet with the results of the aggregate query. · This feature is available as new QuerySet.aggregate()`() and QuerySet.annotate()`() methods, and is covered in detail in the ORM aggregation documentation. Query expressions: · Queries can now refer to a another field on the query and can traverse relationships to refer to fields on related models. This is implemented in the new F object; for full details, including examples, consult the documentation for F expressions. Model improvements: "Unmanaged" models: · You can now control whether or not Django manages the life-cycle of the database tables for a model using the managed model option. This defaults to True, meaning that Django will create the appropriate database tables in syncdb and remove them as part of the reset command. That is, Django manages the database table's lifecycle. · If you set this to False, however, no database table creating or deletion will be automatically performed for this model. This is useful if the model represents an existing table or a database view that has been created by some other means. Proxy models: · You can now create proxy models: subclasses of existing models that only add Python-level (rather than database-level) behavior and aren't represented by a new table. That is, the new model is a proxy for some underlying model, which stores all the real data. · All the details can be found in the proxy models documentation. This feature is similar on the surface to unmanaged models, so the documentation has an explanation of how proxy models differ from unmanaged models. Deferred fields: · In some complex situations, your models might contain fields which could contain a lot of data (for example, large text fields), or require expensive processing to convert them to Python objects. If you know you don't need those particular fields, you can now tell Django not to retrieve them from the database. · You'll do this with the new queryset methods defer() and only(). Testing improvements: · A few notable improvements have been made to the testing framework. Test performance improvements: · Tests written using Django's testing framework now run dramatically faster (as much as 10 times faster in many cases). · This was accomplished through the introduction of transaction-based tests: when using django.test.TestCase, your tests will now be run in a transaction which is rolled back when finished, instead of by flushing and re-populating the database. This results in an immense speedup for most types of unit tests. See the documentation for TestCase and TransactionTestCase for a full description, and some important notes on database support. Test client improvements: A couple of small -- but highly useful -- improvements have been made to the test client: · The test Client now can automatically follow redirects with the follow argument to Client.get() and Client.post(). This makes testing views that issue redirects simpler. · It's now easier to get at the template context in the response returned the test client: you'll simply access the context as request.context. The old way, which treats request.context as a list of contexts, one for each rendered template in the inheritance chain, is still available if you need it. New admin features: Editable fields on the change list?: · You can now make fields editable on the admin list views via the new list_editable admin option. These fields will show up as form widgets on the list pages, and can be edited and saved in bulk. Admin "actions": · You can now define admin actions that can perform some action to a group of models in bulk. Users will be able to select objects on the change list page and then apply these bulk actions to all selected objects. · Django ships with one pre-defined admin action to delete a group of objects in one fell swoop. Conditional view processing: · Django now has much better support for conditional view processing using the standard ETag and Last-Modified HTTP headers. This means you can now easily short-circuit view processing by testing less-expensive conditions. For many views this can lead to a serious improvement in speed and reduction in bandwidth. URL namespaces: · Django 1.1 improves named URL patterns with the introduction of URL "namespaces." · In short, this feature allows the same group of URLs, from the same application, to be included in a Django URLConf multiple times, with varying (and potentially nested) named prefixes which will be used when performing reverse resolution. In other words, reusable applications like Django's admin interface may be registered multiple times without URL conflicts. Other new features and changes introduced since Django 1.0 include: · The CSRF protection middleware has been split into two classes -- CsrfViewMiddleware checks incoming requests, and CsrfResponseMiddleware processes outgoing responses. The combined CsrfMiddleware class (which does both) remains for backwards-compatibility, but using the split classes is now recommended in order to allow fine-grained control of when and where the CSRF processing takes place. · reverse() and code which uses it (e.g., the {% url %} template tag) now works with URLs in Django's administrative site, provided that the admin URLs are set up via include(admin.site.urls) (sending admin requests to the admin.site.root view still works, but URLs in the admin will not be "reversible" when configured this way). · The include() function in Django URLconf modules can now accept sequences of URL patterns (generated by patterns()) in addition to module names. · Instances of Django forms (see the forms overview now have two additional methods, hidden_fields() and visible_fields(), which return the list of hidden -- i.e., -- and visible fields on the form, respectively. · The redirect_to generic view (see the generic views documentation) now accepts an additional keyword argument permanent. If permanent is True, the view will emit an HTTP permanent redirect (status code 301). If False, the view will emit an HTTP temporary redirect (status code 302). · A new database lookup type -- week_day -- has been added for DateField and DateTimeField. This type of lookup accepts a number between 1 (Sunday) and 7 (Saturday), and returns objects where the field value matches that day of the week. See the full list of lookup types for details. · The {% for %} tag in Django's template language now accepts an optional {% empty %} clause, to be displayed when {% for %} is asked to loop over an empty sequence. See the list of built-in template tags for examples of this. · The dumpdata management command now accepts individual model names as arguments, allowing you to export the data just from particular models. · There's a new safeseq template filter which works just like safe for lists, marking each item in the list as safe. · Cache backends now support incr() and decr() commands to increment and decrement the value of a cache key. On cache backends that support atomic increment/decrement -- most notably, the memcached backend -- these operations will be atomic, and quite fast. · Django now can easily delegate authentication to the web server via a new authentication backend that supports the standard REMOTE_USER environment variable used for this purpose. · There's a new django.shortcuts.redirect() function that makes it easier to issue redirects given an object, a view name, or a URL. · The postgresql_psycopg2 backend now supports native PostgreSQL autocommit. This is an advanced, PostgreSQL-specific feature, that can make certain read-heavy applications a good deal faster.


Django Related Software