Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. Built 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. It’s free and open source.

1. Ridiculously fast.
   • Django was designed to help developers take applications from concept to completion as quickly as possible.
2. Reassuringly secure.
   • Django takes security seriously and helps developers avoid many common security mistakes.
3. Exceedingly scalable.
   • Some of the busiest sites on the Web leverage Django’s ability to quickly and flexibly scale.

A model is the single, definitive source of information about your data. It contains the essential fields and behaviors of the data you’re storing. Generally, each model maps to a single database table.

The basics:

Each model is a Python class that subclasses django.db.models.Model.

Each attribute of the model represents a database field.

With all of this, Django gives you an automatically-generated database-access API

To design URLs for an app, you create a Python module informally called a URLconf (URL configuration). This module is pure Python code and is a mapping between URL path expressions to Python functions (your views).

This mapping can be as short or as long as needed. It can reference other mappings. And, because it’s pure Python code, it can be constructed dynamically.

Django also provides a way to translate URLs according to the active language. See the internationalization documentation for more information.

A view function, or view for short, is simply a Python function that takes a Web request and returns a Web response. This response can be the HTML contents of a Web page, or a redirect, or a 404 error, or an XML document, or an image . . . or anything, really. The view itself contains whatever arbitrary logic is necessary to return that response. This code can live anywhere you want, as long as it’s on your Python path. There’s no other requirement–no “magic,” so to speak. For the sake of putting the code somewhere, the convention is to put views in a file called views.py, placed in your project or application directory.

GET and POST are the only HTTP methods to use when dealing with forms.

Django’s login form is returned using the POST method, in which the browser bundles up the form data, encodes it for transmission, sends it to the server, and then receives back its response.

GET, by contrast, bundles the submitted data into a string, and uses this to compose a URL. The URL contains the address where the data must be sent, as well as the data keys and values. You can see this in action if you do a search in the Django documentation, which will produce a URL of the form https://docs.djangoproject.com/search/?q=forms&release=1.

GET and POST are typically used for different purposes.

Any request that could be used to change the state of the system - for example, a request that makes changes in the database - should use POST. GET should be used only for requests that do not affect the state of the system.

Django provides a range of tools and libraries to help you build forms to accept input from site visitors, and then process and respond to the input.

At the heart of this system of components is Django’s Form class. In much the same way that a Django model describes the logical structure of an object, its behavior, and the way its parts are represented to us, a Form class describes a form and determines how it works and appears.

One of the most powerful parts of Django is the automatic admin interface. It reads metadata from your models to provide a quick, model-centric interface where trusted users can manage content on your site. The admin’s recommended use is limited to an organization’s internal management tool. It’s not intended for building your entire front end around.

The admin has many hooks for customization, but beware of trying to use those hooks exclusively. If you need to provide a more process-centric interface that abstracts away the implementation details of database tables and fields, then it’s probably time to write your own views.

Being a web framework, Django needs a convenient way to generate HTML dynamically. The most common approach relies on templates. A template contains the static parts of the desired HTML output as well as some special syntax describing how dynamic content will be inserted. For a hands-on example of creating HTML pages with templates.

A Django project can be configured with one or several template engines (or even zero if you don’t use templates). Django ships built-in backends for its own template system, creatively called the Django template language (DTL), and for the popular alternative Jinja2. Backends for other template languages may be available from third-parties.

Django defines a standard API for loading and rendering templates regardless of the backend. Loading consists of finding the template for a given identifier and preprocessing it, usually compiling it to an in-memory representation. Rendering means interpolating the template with context data and returning the resulting string.

Django comes with a user authentication system. It handles user accounts, groups, permissions and cookie-based user sessions.

The Django authentication system handles both authentication and authorization. Briefly, authentication verifies a user is who they claim to be, and authorization determines what an authenticated user is allowed to do. Here the term authentication is used to refer to both tasks.

• Users
• Permissions: Binary (yes/no) flags designating whether a user may perform a certain task.
• Groups: A generic way of applying labels and permissions to more than one user.
• A configurable password hashing system
• Forms and view tools for logging in users, or restricting content
• A pluggable backend system

• Password strength checking
• Throttling of login attempts
• Authentication against third-parties (OAuth, for example)

The goal of internationalization and localization is to allow a single Web application to offer its content in languages and formats tailored to the audience.

Django has full support for translation of text, formatting of dates, times and numbers, and time zones.

• It allows developers and template authors to specify which parts of their apps should be translated or formatted for local languages and cultures.
• It uses these hooks to localize Web apps for particular users according to their preferences. Obviously, translation depends on the target language, and formatting usually depends on the target country. This information is provided by browsers in the Accept-Language header. However, the time zone isn’t readily available.

• internationalization : Preparing the software for localization. Usually done by developers.
• localization : Writing the translations and local formats. Usually done by translators.

• Cross site scripting (XSS) protection
• Cross site request forgery (CSRF) protection
• SQL injection protection
• Clickjacking protection
• SSL/HTTPS
• Host header validation
• Session security
• User-uploaded content

• Flask is a web application framework written in Python. Armin Ronacher, who leads an international group of Python enthusiasts named Pocco, develops it. Flask is based on Werkzeug WSGI toolkit and Jinja2 template engine. Both are Pocco projects.
• Flask is often referred to as a micro framework. It aims to keep the core of an application simple yet extensible. Flask does not have built-in abstraction layer for database handling, nor does it have form a validation support. Instead, Flask supports the extensions to add such functionality to the application.

The route() function of the Flask class is a decorator, which tells the application which URL should call the associated function. app.route(rule, options):

• The rule parameter represents URL binding with the function.
• The options is a list of parameters to be forwarded to the underlying Rule object.

Modern web frameworks use the routing technique to help a user remember application URLs. It is useful to access the desired page directly without having to navigate from the home page.

Http protocol is the foundation of data communication in world wide web. Different methods of data retrieval from specified URL are defined in this protocol. There are mainly methods are: GET, POST, PUT, DELETE

By default, the Flask route responds to the GET requests. However, this preference can be altered by providing methods argument to route() decorator. In order to demonstrate the use of POST method in URL routing, first let us create an HTML form and use the POST method to send form data to a URL.

• it is possible to parse data between html file. And for better user experience so for this flask work as a backbon.
• It is possible to return the output of a function bound to a certain URL in the form of HTML.However, generating HTML content from Python code is cumbersome, especially when variable data and Python language elements like conditionals or loops need to be put. This would require frequent escaping from HTML.
• The term ‘web templating system’ refers to designing an HTML script in which the variable data can be inserted dynamically. A web template system comprises of a template engine, some kind of data source and a template processor.

The data from a client’s web page is sent to the server as a global request object. In order to process the request data, it should be imported from the Flask module. for this flask provide some build in request object to obsess the user request.

• Python has an in-built support for SQlite. SQlite3 module is shipped with Python distribution.
• Flask also support the database like SQLAlchemy and it is easy to integrate with mongoDB.
• Using raw SQL in Flask web applications to perform CRUD operations on database can be tedious. Instead, SQLAlchemy, a Python toolkit is a powerful OR Mapper that gives application developers the full power and flexibility of SQL. Flask-SQLAlchemy is the Flask extension that adds support for SQLAlchemy to your Flask application.