Django Basic 2---URL Controller module with views View module

URL Controller:

is primarily used for URL distribution functions, such as user input: 127.0.0.1:8080/apptest

Configure URLs to enable Django to correctly identify user input

URL Not configured error type is as follows:

Make the correct URL configuration:

Open the urls.py file under project:

The initial URLs file is as follows:

 from Import URL  from Import Admin  from Import  = [    url (r'^admin/', Admin.site.urls),]

Make your URL configuration in the Urlpatterns dictionary

Such as:

You should first import your view functions: From appname Import views

URL (regex,view,kwargs), fill in the path of the regular expression, so that it can be matched to the input URL, the second parameter calls the view of the handler function: URL () must be followed by commas to other URLs, or Django does not recognize

A basic request response is: The user enters the URL-------the URL controller to match------look for the corresponding processing function in the appropriate view

 from  Django.conf.urls import   URL  from  django.contrib import   admin  from  app01 import   viewsurlpatterns  = [url (r  "  ^admin/  "   " show_time/ "  , Views.show_time),] 

Then the corresponding URL processing function in views.py code, where the processing function as far as possible with the path name has some relevance, the error is also good to find to modify

The Show_time () handler function in the view:

 from Import Render,httpresponse Import Time ... .. def Show_time (Request):  The parameters of the function must have, accept HTTP requests and processing are sealed in    the parameter = time.time    ()return  #  as a test here returns an HTTP response

Start this webapp:

1.

cmd or cmd under Pycharm:

Command: Python manage.py runserver 8080 The port number here does not fill in the occupied port number on the line

2.

Pycharm run log in the upper right corner can also run the current project's WebApp

There are two types of naming rules for URLs: 1, no naming convention 2, naming conventions

The first type:

The URL matches the regular as long as it can match on the line, such as the URL (r '/d+/d+ ',) as long as the input URL has a number, Django can find and then go to the view to find processing function

The second type:

Regular expressions are grouped: such as URL (R ' ^article/(? P<year> (\d+))/(? p<month>\d+) ', views.article_year_month) name the URL, and the function parameter must correspond to the same function and parameters as the named form: Article_year_month (request, year, month )

Distribution features for URLs:

The starting point of this problem is that if a project has a lot of Web applications and a lot of url,url matching all written in urls.py, error is not easy to find, conditioning is not clear, so URL distribution is a very important point.

Features: Place the URL corresponding to the Web application under Application, new urls.py, yellow labeled as new, red callout as primary route

This seems to clear a lot of regulations, the sub-chain under the blog all placed under the blog's URLs:

The corresponding URLs in the project Master route describe how the distribution function should be used:

including another URLconf
    1. Import the Include () function:from django.conf.urls Import URL, include
    2. Add a URL to urlpatterns:  url (r ' ^blog/', include (' Blog.urls '))

Usage: In the main route URLs such modifications: New urlconf under the Include module

From Django.conf.urls import URL, include

Urlpatterns Add the following content:

If you have two webapp: one is blog one for pay

Urlpatterns = [
URL (r ' ^blog/', include (' Blog.urls ')),

URL (r ' pay/', include (' Pay.urls '))

......

.......
]

Then add the code to the corresponding webapp in the following URLs:

""" URL distribution function, assigning URLs to each webapp under URLs """  from Import URL  from Import  = [    #  url (r ' ^clock_time/', views.clock_time),]

This is then accessed by the browser: the URL should be written so that it can be accessed, because this strand has been assigned to the URL under the blog

Views View module:

An HTTP request produces two Core objects:

HTTP Request: HttpRequest object

HTTP response: HttpResponse object

Location: django.http

HttpRequest Object

Class Httprequest[source]
Property

Unless otherwise noted, all properties should be treated as read-only.

Httprequest.scheme
A string that represents the request scheme (HTTP or HTTPS is typically).

Httprequest.body
The original HTTP request body as a byte string. This is useful for processing data in a way that differs from traditional HTML forms: Binary images, XML payloads, and so on. To work with traditional form data, use Httprequest.post.

You can also read HttpRequest using a similar file-like interface. See Httprequest.read ().

Httprequest.path
A string representing the full path of the requested page, excluding the scheme or domain.

Example: "/music/bands/the_beatles/"

Httprequest.path_info
Under certain Web server configurations, the URL portion of the host name is divided into the script prefix section and the path Information section. Path_info regardless of the Web server used, this property always contains the path information portion of the path. Using this instead of path makes it easier for your code to move between the test and deployment servers.

For example, if Wsgiscriptalias your application is set to "/minfo", the path may be "/minfo/music/bands/the_beatles/" and Path_info "/music/bands/the_ Beatles/".

Httprequest.method
A string that represents the HTTP method used in the request. This guarantee is in uppercase. For example:

if Request.method = = ' GET ':
Do_something ()
elif Request.method = = ' POST ':
Do_something_else ()
Httprequest.encoding
Represents the currently encoded string used to decode the form submission data (or none, indicating the use of the Default_charset setting). You can write this property to change the encoding that is used to access the form data. Any subsequent property accesses (for example, read get or POST) will use the new encoding value. This is useful if you know that the form data is not in Default_charset encoding.

Httprequest.content_type
A string representing the MIME type of the request, resolved from the Content_Type header.

Httprequest.content_params
The Dictionary of key/value parameters contained in the Content_Type header.

Httprequest.get
A dictionary-like object that contains all the given HTTP get parameters. See the documentation below Querydict.

Httprequest.post
A dictionary-like object that contains all the given HTTP POST parameters, provided the request contains form data. See the documentation below Querydict. If you need to access the raw data or non-form data published in the request, Httprequest.body access this data by property instead.

It is possible for a request to send an empty post dictionary via post-for example, if the form is requested through the post HTTP method but does not contain form data. Therefore, you should not use the check post method; Instead, use (see). If request. Postif Request.method = = "POST" Httprequest.method

Post it does not contain file upload information. Look at files.

HttpRequest.Cookies
A dictionary that contains all cookies. The key and value are strings.

Httprequest.files
A dictionary-like object that contains all the uploaded files. Each key files is name from. Each value is one. <input type= "file" Name= ""/>filesuploadedfile

Files will only contain data if the request method is post and <form> published to the requested method enctype= "Multipart/form-data". Otherwise, files will be an empty dictionary-style object.

Django Basic 2---URL Controller module with views View module