After running into all sorts of bizarre little bugs with Java as my backend, I chose python as my backend for my last web project in college. My feeling for Django is that it is simple, which greatly simplifies the development time. The most important thing is that it is based on the scripting language of python, which saves all kinds of small errors encountered during compilation. Let's start developing records.
First select the environment. Here, I chose to install ubuntu14.04 in the virtual machine as the background, and allocated 3GB of memory for this virtual machine (larger, or card), two network cards, one for networking, and one for connecting with Connect locally (for fear that the network cable will suddenly drop), the IP can be assigned casually, as long as it can communicate normally.
python version: 2.7.6
Django version: 1.11.8
Reference tutorial: https://code.ziqiangxuetang.com/django/django-tutorial.html
The software installation process is omitted, and the project is officially started as follows:
The first step is to switch to the working directory, and future projects are placed in this directory
root@ubuntu:~# cd python/django/
The second part, use the command to open a new project
root@ubuntu:~/python/django# django-admin startproject codeManageAndShare
After using this command, a directory named "codeManageAndShare" will be generated in the current directory, which is equivalent to opening a project, and then each project in this project is called app. Entering this directory, you can see that many directories and files are generated. Among them, there is a directory with the same name as the project. There are many python script files in this directory. The most used ones are settings.py and urls.py. These files are used for settings and URL diversion respectively. For example, when you need to set which hosts can be accessed, you need to set them in settings.py. When the access comes, you need to set up what to display in urls.py.
The third part , use the command to open a new app
After the project is established, in order to achieve specific functions, you need to create a project. To create a project, you need to use the "manage.py" script in the current project directory:
root@ubuntu:~/python/django/codeManageAndShare# python manage.py startapp app_selfPart
In this way, an app (project) is established. According to the name, it can be seen that the function of this project is to create a personal module. When the command is used, a new directory named "app_selfPart" will be generated in the current directory. A lot of script files are also generated in this directory, among which the two most used are "models.py" and "views.py", whose functions are to create a database and create a view respectively.
Some commands:
Run the server (the port is arbitrarily specified, and the IP is written so that all IPs can be accessed. If there is no IP, only the local can be accessed by default. You also need to change AllowHost in setting.py in the codeManageAndShare directory (change the parameter to "" *"" (with quotation marks))):
root@ubuntu:~/python/django/codeManageAndShare# python manage.py runserver 0.0.0.0:8000
Synchronize the database (the following two commands can be executed one by one)
Commit the changes to generate the changes file:
root@ubuntu:~/python/django/codeManageAndShare# python manage.py makemigrations
Sync changes into the database:
root@ubuntu:~/python/django/codeManageAndShare# python manage.py migrate
Personal understanding :
After the server is running, you can open the browser on the real machine to access through the IP and port number. The process of accessing is to initiate an access request through the browser, and then the request arrives at port 8000 monitored by the server, and then the "codeManageAndShare" in "codeManageAndShare" urls.py" starts working according to "setting.py", matches the requested URL according to something similar to a regular expression configured in "urls.py", and then sends the request to the "views" in the matching app .py", some functions are written in advance in "views.py", these functions specify the processing of data, the parameter of the function is the requested "request", when the processing is completed, there will be a " return" statement to return the result of the processing, the result of this processing, currently known:
1. Render a template in the "templates" directory (return render(request,'selfPart.html')) (this directory must be created under the current app, but it will automatically go to this directory when looking for it), The rendering process can use the function to pass in the parameters taken from the database (the method of using variables in the template during rendering is "{{var}}") and finally return the rendering result to the request through return;
2. Directly return text information (return JsonResponse("some text", safe=False)), the returned text can be seen directly in the browser;
3. Directly redirect (return HttpResponseRedirect('/selfPart')), process when accessing this URL, and then redirect to a new URL.
For the database, as mentioned above, use the "models.py" script in each app. The content of this script is roughly as shown below:
In the above picture, you can see that it is very different from the general database sql language. My understanding is that Django encapsulates the well-known sql language and converts it into this kind of method, which is defined here using variables. Data format, and then you can use commands in other scripts or command lines to process the database. For example, to find data, you can use "get" directly. After receiving these commands, Django automatically converts them to "select *" from..." SQL statements like this are sent to the database for execution. To filter, you can use "filter" directly. The data after using these functions is still an object, which is more convenient in the next processing, which greatly facilitates our use and development.
Another very useful function is user authentication. When we need to develop a login module, it takes a lot of time to develop the authentication part. For example, a private interface cannot be accessed by a person who is not logged in, or two The personal pages that a logged-in person sees should be their own personal pages. Django has already done this for us, and we only need it in the views.py script in the app that needs to be authenticated. You can add modifiers, which will be mentioned later.
The above is all made up by me based on my observations! ! !