Django (web framework)
Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.It's a free and open source web application framework written in Python (programming language) by experienced developers.It takes care of much of the hassle of web development, so you can focus on writing your app without needing to reinvent the wheel.
Django is ridiculously fast.It was designed to help developers take applications from concept to completion as quickly as possible.
Django is reassuringly secure.It takes security seriously and helps developers avoid many common security mistakes.
Django is exceedingly scalable.Some of the busiest sites on the web leverage Django's ability to quickly and flexibly scale.
Django follows the model-view-controller (MVC) architectural pattern
Django also provides an optional administrative create, read, update and delete interface that is generated dynamically through introspection and configured via admin models.
We have some really exciting websites using Django on this list many of which are the leading sites in the world right now like Disqus , Pinterest,Instagram,Mahalo, Bitbucket, Mozilla Support, The Onion, dpaste, chess, DjangoSites, Coordinato, Django Girls, Reddit Gifts, Yipit so to say that Django isn't production ready is to say what we can't recognize the immense power some of these sites have. We have some really exciting websites using Django on this list, many of which are the leading sites in the world right now, so to say that Django isn’t production ready is to say that we can’t recognize the immense power some of these sites have.
- 1 History 
- 2 Design philosophies 
- 3 features
- 4 community
- 5 Other Languages
- 6 Version History
- 7 References
Django started when Adrian Holovaty and Simon Willison were working for a year at the Lawrence Journal-World newspaper back in the fall of 2003.It was released publicly under a BSD licence in July 2005.
In June 2008, a newly formed Django software Foundation (DSF) would maintain Django in the future.
Design philosophies 
This is about the fundamental philosophies Django's developers have used in creating the framework.
- Loose Coupling : A fundamental goal of Django's stack is loose coupling and tight cohesion. The various layers of the framework should not 'know' about each other unless absolutely necessary.
- Less Code :Django apps should use as little code as posible; they should lack boilerplate. Django should take full advantage of Python's dynamic capabilities, such as introspection.
- Quick Development :The point of a web framework in the 21st century is to make the tedious aspects of web development fast. Django should allow for incredibly quick web development.
- Don’t repeat yourself (DRY) : Every distinct concept or piece of data should live in one place only.
- Explicit is better than implicit :It means Django should not do too much magic. Magic should not happen unless there's a really good reason for it. Magic is worth using only if it creates a huge convenience unattainable in other ways, and it's not implemented in a way that confuses developers who are trying to learns hot to use the feature.
- Consistency : Consistency applies to everything from low-level to high level.
- Explicit is better than implicit :Fields should not assume certain behaviors based solely on the name of the field. This requires too much knowledge of the system and is prone to errors. Instead, behaviors should be based on keyword arguments and, in some cases, on the type of the field.
- Include all relevant domain logic :This is why both the data represented by a model and information about it are defined in the model class; all the information needed to understand a given model should be stored in the model.
- SQL Efficiency :It should execute SQL statement as few times as possible, and it should optimize statements internally.
- Terse, powerful syntax :The database API should allow rich, expressive statements in as little syntax as possible. It should not rely on importing other modules or helper objects.
- Option to drop into raw SQL easily, when needed : The database API should realize it’s a shortcut but not necessarily an end-all-be-all. The framework should make it easy to write custom SQL – entire statements, or just custom WHERE clauses as custom parameters to API calls.
- Loose coupling :Django URL system should allow URLs for the same app to be different in different contexts.
- Infinite flexibility :URLs shold be as flexible as possible.
- Encourage Best Practices :The framework should make design pretty URLs easy.
- Definitive URLS :Technically, foo.com/bar and foo.com/bar/ are two different URLs, and search-engine robots would treat them as separate pages. Django should make an effort to “normalize” URLs so that search-engine robots don’t get confused.
- Simplicity : Writing a view should be as simple as writing a Python function. Developers shouldn’t have to instantiate a class when a function will do.
- Use request objects :Views should have access to a request object – an object that stores metadata about the current request. The object should be passed directly to a view function, rather than the view function having to access the request data from a global variable. This makes it light, clean and easy to test views by passing in “fake” request objects.
- Loose coupling :A view should not care about which template system the developer uses – or even whether a template system is used at all.
- Differentiate between GET and POST :GET and POST are distinct; developers should explicitly use one or the other. The framework should make it easy to distinguish between GET and POST data.
- Separate logic from presentation :We see a template system as a tool that controls presentation and presentation-related logic- and that's it.The template system should not support functionality that goes beyond this basic goal.
- Discourage Redundancy :The majority of dynamic websites use some sort of common sitewide design.The Django template system should make it easy to store those elements in a single place, eliminating duplicate code.
- Be Decoupled from HTML :The template system should not be designed so that it only outputs HTML. It should be equally good at generating other text-based formats or just plain text
- XML should not be used for template languages :usin an XML engine to parse templates introduces a whole new world of human error in editing templates and incurs an unacceptable level of overhead in template processing
- Assume Designer Competence :The template system should not be designed so that templates necessarily are displayed nicely in WYSIWYG editors such as Dreamweaver.That is too severe of limitation and wouldn't allow the syntax to be as nice as it is.
- Treat WhiteSpace Obviously :The template system shouldn't do magic things with whitespaces. If a template includes whitespaces, the system should treat the whitespace as it treats text - just display it.
- Don't Invent Programming Language :The goal is to offer just enough programming-esque functionality, such as branching and looping, this is essential for making presentation-related decisions. The Django Template Language (DTL) aims to avoid advanced logic.
- Safety and Security :The template system, out of the box, should forbid the inclusion of malicious code such as command that delete database records.
- Extensibility :The template system should recognize that advanced template authors may want to extend its technology.
- Less code :A cache should be as fast as possible. Hence, all framework code surrounding the cache backend should be kept to the absolute minimum, especially for get() operations.
- Consistency :The cache API should provide a consistent interface across the different cache backends.
- Extensibility :The cache API should be extensible at the application level based on the developer’s needs (for example, see Cache key transformation).
Django framework can be seen as MVC model.It consists of an object-relational mapper (ORM) which mediates between data models (defined as Python classes) and a relational database(M:Model), a system for processing HTTP requests with a web templating system (V:View) and a regular-expression-based URL dispatcher (C:Controller)
Also included in the core framework are:
- Web server for development and testing. It's a lightweight and standalone.
- An interface to the built in unit test framework in Python (programming language).
- A serialization system which can produce and read XML/JSON of Django model instances.
- Caching framework that can use any of several cache methods.
- form serialization and validation system which can translate between HTML forms and values suitable for storage in the database.
- Support fore middleware classes which can intervene at various stages of request processing and carry out custom functions.
- Template system that utilizes the concept of inheritance borrowed from object-oriented programming.
- An internal dispatcher system which allows components of an application to communicate events to each other via pre-defined signals.
- System for extending the capabilities of the template engine.
- An internationalization system, including translations of Django's own components into a variety of languages.
Django bundles a number of applications in its contrib package, including:
- Authentication System.
- Dynamic Administrative Interface.
- Tools for generating RSS and Atom syndication feeds.
- Tools for generating Google Sitemaps.
- Framework for creating GIS Applications.
- Built-in Mitigation for cross-site request forgery.
- Built-in Mitigation for cross-site scripting.
- Built-in Mitigation for SQL injection.
- Built-in Mitigation for password cracking and other web attacks.
It's a lot of work to design, test and maintain a web application. Many Python and Django projects share common problems. Reusability is the way of life in Python. The Python Package Index (PYPI) has a vast range of packages you can use in your own Python programs. Check out Django packages for existing reusable apps you could incorporate in your project. Django itself is also just a Python package. This means that you can take existing Python packages or Django apps and compose them into your own web project. You only need to write the parts that make your project unique.
This extensibility is mitigated by internal components dependencies. While the Django design philosophy  implies loose coupling, the template filters and tags assume one engine implementation, and both the auth and admin bundled applications require the use of the internal ORM. None of these filters or bundled apps are mandatory to run a Django project, but reusable apps tend to depend on them, encouraging developers to keep using the official stack in order to benefit fully from the apps ecosystem.
Because Django uses WSGI, it can run on any WSGI-compatible web server. Django can be run in conjunction with Apache, NGINX using WSGI, Gunicorn, or Cherokee using flup. Django also includes the ability to launch a FastCGI server, enabling use behind any web server which sypports FastCGI, such as Lighttpd or Hiawatha. It's also possible to use other WSGI-compliant web servers. Django officially supports four database backends: Oracle, SQLite, MySQL and PostgreSQL. Microsoft SQL server can be used with the Django-mssql on Windows machine. While similarly external backends exist for IBM DB2, SQL anywhere and Firebird. There is a fork named Django-nonrel, which supports NoSQL databases, such as MongoDB and Google App Engine's Datastore.
Django also can run with Jython on any java EE APP server such as JBoss. In this case Django-Jython must be installed to provide JDBC drivers for database connectivity, which also provides functionality to compile Django in to a .war suitable for deployment.
DjangoCon is a semiannual conference for Django developers and users. It began in September 2008. DjangoCon is held every year in Europe in June or May.
There is another conference is held in the United States in September every year.
Django's template design has been ported to other languages besides Python, providing decent cross-platform support.
|0.90 ||16 Nov 2005||Not Supported|
|0.91 ||11 Jan 2006||Not Supported|
|0.95 ||29 Jul 2006||Not Supported|
|0.96 ||23 Mar 2007||Not Supported|
|1.0 ||3 Sep 2008||Not Supported|
|1.1 ||29 Jul 2009||Not Supported|
|1.2 ||17 May 2010||Not Supported|
|1.3 ||23 Mar 2011||Not Supported|
|1.4 ||23 Mar 2012||Not Supported|
|1.5 ||26 Feb 2013||Not Supported|
|1.6 ||6 Nov 2013||Not Supported|
|1.7 ||2 Sep 2014||Not Supported|
|1.8 ||1 Apr 2015||Still supported|
|1.9 ||1 Dec 2015||Current Version|