Unless you're planning to build websites and applications that do nothing but\npublish content, and don't accept input from your visitors, you're going to\nneed to understand and use forms.
\nDjango provides a range of tools and libraries to help you build forms to\naccept input from site visitors, and then process and respond to the input.
\nIn HTML, a form is a collection of elements inside <form>...</form> that\nallow a visitor to do things like enter text, select options, manipulate\nobjects or controls, and so on, and then send that information back to the\nserver.
Some of these form interface elements - text input or checkboxes - are built\ninto HTML itself. Others are much more complex; an interface that pops up a\ndate picker or allows you to move a slider or manipulate controls will\ntypically use JavaScript and CSS as well as HTML form <input> elements to\nachieve these effects.
Sama halnya dengan unsur <input>, sebuah formulir harus menentukan dua hal:
dimana URL dimana data sesuai ke masukan pengguna harus kembali
bagaimana: Metode HTTP data harus kembali
As an example, the login form for the Django admin contains several\n<input> elements: one of type="text" for the username, one of\ntype="password" for the password, and one of type="submit" for the\n"Log in" button. It also contains some hidden text fields that the user\ndoesn't see, which Django uses to determine what to do next.
It also tells the browser that the form data should be sent to the URL\nspecified in the <form>’s action attribute - /admin/ - and that it\nshould be sent using the HTTP mechanism specified by the method attribute -\npost.
Ketika unsur 1 dipicu, data dikembalikan ke /admin.
GET dan POSTLink to this heading#GET dan POST adalah hanya cara HTTP digunakan untuk berhubungan dengan formulir.
Django's login form is returned using the POST method, in which the browser\nbundles up the form data, encodes it for transmission, sends it to the server,\nand then receives back its response.
GET, by contrast, bundles the submitted data into a string, and uses this\nto compose a URL. The URL contains the address where the data must be sent, as\nwell as the data keys and values. You can see this in action if you do a search\nin the Django documentation, which will produce a URL of the form\nhttps://docs.djangoproject.com/search/?q=forms&release=1.
GET and POST adalah khususnya digunakan untuk tujuan berbeda.
Any request that could be used to change the state of the system - for example,\na request that makes changes in the database - should use POST. GET\nshould be used only for requests that do not affect the state of the system.
GET would also be unsuitable for a password form, because the password\nwould appear in the URL, and thus, also in browser history and server logs,\nall in plain text. Neither would it be suitable for large quantities of data,\nor for binary data, such as an image. A Web application that uses GET\nrequests for admin forms is a security risk: it can be easy for an attacker to\nmimic a form's request to gain access to sensitive parts of the system.\nPOST, coupled with other protections like Django's CSRF protection offers more control over access.
On the other hand, GET is suitable for things like a web search form,\nbecause the URLs that represent a GET request can easily be bookmarked,\nshared, or resubmitted.
Handling forms is a complex business. Consider Django's admin, where numerous\nitems of data of several different types may need to be prepared for display in\na form, rendered as HTML, edited using a convenient interface, returned to the\nserver, validated and cleaned up, and then saved or passed on for further\nprocessing.
\nDjango's form functionality can simplify and automate vast portions of this\nwork, and can also do it more securely than most programmers would be able to\ndo in code they wrote themselves.
\nDjango menangani tiga bagian berbeda dari pekerjaan melibatkan dalam formulir-formulir:
\nmempersiapkan dan menyusun kembali data untuk membuat itu untuk pengiriman
membuat formulir HTML untuk data
menerima dan mengolah formulir-formulir diajukan dan data dari klien
Itu memungkinkan menulis kode yang melakukan semua ini secara manual, tetapi Django dapat merawat itu semua untuk anda.
\nKami telah menggambarkan formulir HTML dengan ringkas, tetapi sebuah HTML 1 hanya satu bagian dari mesin yang dibutuhkan.
In the context of a Web application, 'form' might refer to that HTML\n<form>, or to the Django Form that produces it, or to the\nstructured data returned when it is submitted, or to the end-to-end working\ncollection of these parts.
Form DjangoLink to this heading#At the heart of this system of components is Django's Form class. In\nmuch the same way that a Django model describes the logical structure of an\nobject, its behavior, and the way its parts are represented to us, a\nForm class describes a form and determines how it works and appears.
In a similar way that a model class's fields map to database fields, a form\nclass's fields map to HTML form <input> elements. (A ModelForm\nmaps a model class's fields to HTML form <input> elements via a\nForm; this is what the Django admin is based upon.)
A form's fields are themselves classes; they manage form data and perform\nvalidation when a form is submitted. A DateField and a\nFileField handle very different kinds of data and have to do\ndifferent things with it.
A form field is represented to a user in the browser as an HTML "widget" - a\npiece of user interface machinery. Each field type has an appropriate default\nWidget class, but these can be overridden as\nrequired.
\nKetika membangun sebuah obyek di Django, kami umumnya:
\nget hold of it in the view (fetch it from the database, for example)
lewatkan ke konteks cetakan
perluas itu pada markah HTML menggunakan variabel cetakan
Membangun formulir dalam cetakan melibatkan hampir pekerjaan sama seperti membangun jenis lain dari obyek, tetapi ada beberapa kunci perbedaan.
\nIn the case of a model instance that contained no data, it would rarely if ever\nbe useful to do anything with it in a template. On the other hand, it makes\nperfect sense to render an unpopulated form - that's what we do when we want\nthe user to populate it.
\nJadi ketika kami menangani instance model dalam tampilan, kami khususnya mengambil itu dari basisdata. Ketika kami sedang berhubungan dengan seuah formulir kami khususnya menginstansiasi itu dalam tampilan.
\nKetika kami menginstansiasi sebuah formulir, kami dapat memilih meninggalkan itu kosong atau itu sudah-terisi, sebagai contoh dengan:
\ndata dari instance model tersimpan (seperti dalam kasus dari formulir admin untuk penyuntingan).
data yang kami telah kumpulkan dari sumber lain
data diterima dari pengajuan formulir HTML sebelumnya
Kasus terakhir ini paling menarik, karena itu memungkinkan untuk pengguna tidak hanya membaca jaringan situs, tetapi juga mengirim informasi kembali ke jaringan situs.
\nMisalnya anda ingin membuat sebuah formulir sederhana pada situs jaringan anda, untuk mendapatkan nama pengguna, anda akan butuh sesuatu seperti ini di cetakan anda:
\n<form action="/your-name/" method="post">\n <label for="your_name">Your name: </label>\n <input id="your_name" type="text" name="your_name" value="{{ current_name }}">\n <input type="submit" value="OK">\n</form>\nIni memberitahukan perambah untuk mengembalikan data formulir ke URL /your-name/, menggunakan cara POST. Dia akan menampilkan bidang teks, label "Nama anda:", dan tombol ditandai "OK". Jika konteks cetakan mengandung variabel current_name, yang akan digunakan untuk pra-isian bidang your_name.
Anda akan butuh sebuah tampilan yang membangun cetakan mengandung formulir HTML, dan dapat mendukung bidang current_name sewajarnya.
Ketika formulir diajukan, permintaan POST yang dikirim ke peladen akan mengandung data formulir.
Sekarang anda akan juga butuh sebuah tampilan sesuai ke URL /your-name/ yang akan menemukan pasangan kunci/nilai yang sesuai di permintaan, dan kemudian mengolah mereka.
Ini adalah formulir sangat sederhana. Dalam praktiknya, sebuah formulir mungkin mengandung lusinan atau ratusan bidang, banyak yang mungkin butuh untuk di pra-kumpulkan, dan kami mungkin mengharapkan pengguna untuk bekerja melalui lingkaran ajukan-sunting beberapa kali sebelum menutup tindakan.
\nKami mungkin membutuhkan beberapa pengesahan untuk muncul dalam peramban, bahkan sebelum formulir diajukan; kami mungkin ingin menggunakan bidang-bdiang lebih rumit, yang mengizinkan pengguna melakukan hal-hal seperti mengambil tanggal dari kalender dan seterusnya.
\nPada titik ini itu lebih mudah mendapatkan Django melakukan kebanyakan dari pekerjaan ini untuk kita.
\nFormLink to this heading#Kami sudah mengetahui apa kami inginkan formulir HTML kami terlihat seperti. Titik mulai kami untuk itu di Django adalah ini:
\nforms.pyfrom django import forms\n\nclass NameForm(forms.Form):\n your_name = forms.CharField(label='Your name', max_length=100)\nIni menentukan kelas Form dengan bidang tunggal (your_name). Kami telah berlakukan label ramah-manusia pada bidang, yang akan muncul dalam 1 ketika itu dibangun (meskipun dalam kasus ini, label kami tentukan sebenarnya sama satu yang akan dibangkitkan otomatis jika kami telah menghilangkan itu).
Panjang masimal bidang diizinkan ditentukan oleh max_length. Ini melakukan dua hal. Itu menaruh maxlength="100" pada HTML 1 (jadi peramban harus mencegah pengguna dari memasuki ebih dari sejumlah karakter dalam tempat pertama). Itu juga berarti bahwa ketika Django menerima formulir kembali dari peramban, itu akan mensahkan panjang dari data.
Sebuah instance Form mempunyai sebuah metode is_valid(), yang menjalankan fungsi untuk semua bidang-bidangnya. Ketika metode ini dipanggil, jika semua bidang mengadnung data sah, itu akan:
kembali True
tempatkan data formulir dalam atribut cleaned_data nya.
Formulir keseluruhan, ketika dibangun untuk pertama kali, akan kelihatan seperti:
\n<label for="your_name">Your name: </label>\n<input id="your_name" type="text" name="your_name" maxlength="100" required>\nNote that it does not include the <form> tags, or a submit button.\nWe'll have to provide those ourselves in the template.
Form data sent back to a Django website is processed by a view, generally the\nsame view which published the form. This allows us to reuse some of the same\nlogic.
\nTo handle the form we need to instantiate it in the view for the URL where we\nwant it to be published:
\nviews.pyfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\n\nfrom .forms import NameForm\n\ndef get_name(request):\n # if this is a POST request we need to process the form data\n if request.method == 'POST':\n # create a form instance and populate it with data from the request:\n form = NameForm(request.POST)\n # check whether it's valid:\n if form.is_valid():\n # process the data in form.cleaned_data as required\n # ...\n # redirect to a new URL:\n return HttpResponseRedirect('/thanks/')\n\n # if a GET (or any other method) we'll create a blank form\n else:\n form = NameForm()\n\n return render(request, 'name.html', {'form': form})\nIf we arrive at this view with a GET request, it will create an empty form\ninstance and place it in the template context to be rendered. This is what we\ncan expect to happen the first time we visit the URL.
If the form is submitted using a POST request, the view will once again\ncreate a form instance and populate it with data from the request: form =\nNameForm(request.POST) This is called "binding data to the form" (it is now\na bound form).
We call the form's is_valid() method; if it's not True, we go back to\nthe template with the form. This time the form is no longer empty (unbound)\nso the HTML form will be populated with the data previously submitted, where it\ncan be edited and corrected as required.
If is_valid() is True, we'll now be able to find all the validated form\ndata in its cleaned_data attribute. We can use this data to update the\ndatabase or do other processing before sending an HTTP redirect to the browser\ntelling it where to go next.
Kami tidak perlu melakukan banyak dalam cetakan``name.html``kami:
\n<form action="/your-name/" method="post">\n {% csrf_token %}\n {{ form }}\n <input type="submit" value="Submit">\n</form>\nSemua bidang formulir dan atribut mereka akan dikeluarkan kedalam markah HTML dari {{ form }} itu dengan bahasa cetakan Django.
Kami sekarang memiliki formulir jaringan yang bekerja, digambarkan oleh Django Form, diolah oleh tampilan, dan dibangun sebagai HTML <form>.
That's all you need to get started, but the forms framework puts a lot more at\nyour fingertips. Once you understand the basics of the process described above,\nyou should be prepared to understand other features of the forms system and\nready to learn a bit more about the underlying machinery.
\nForm.Link to this heading#All form classes are created as subclasses of either django.forms.Form\nor django.forms.ModelForm. You can think of ModelForm as a\nsubclass of Form. Form and ModelForm actually inherit common\nfunctionality from a (private) BaseForm class, but this implementation\ndetail is rarely important.
Perbedaan diantara Bound and unbound forms adalah penting:
\nSebuah formulir tidak terikat tidak mempunyai data terkait dengan itu. Ketika dibanguk ke pengguna, itu akan kosong atau mengandung nilai awalan.
Sebuah formulir ikatan telah mengajukan data, dan kemudian dapat digunakan untuk memberitahu jika data adalah sah. Jika sebuah ikatan tidak sah dibangun, itu dapat menyertakan pesan-pesan kesalahan berderet mengatakan pengguna apa yang data untuk diperbaiki.
Atribut formulir is_bound akan memberitahu anda apakah sebuah formulir mempunyai data terikat ke itu atau tidak.
Pertimbangkan formulir lebih berguna dari contoh minimal kami diatas, yang kami dapat gunakan untuk menerapkan kegunaan "hubungi kami" pada situs jaringan pribadi:
\nforms.pyfrom django import forms\n\nclass ContactForm(forms.Form):\n subject = forms.CharField(max_length=100)\n message = forms.CharField(widget=forms.Textarea)\n sender = forms.EmailField()\n cc_myself = forms.BooleanField(required=False)\nOur earlier form used a single field, your_name, a CharField. In\nthis case, our form has four fields: subject, message, sender and\ncc_myself. CharField, EmailField and\nBooleanField are just three of the available field types; a full list\ncan be found in Bidang formulir.
Setiap bidang formulir mempunyai Widget class 1 sesuai, yang gilirannya sesuai pada sebuah widget formulir HMTL seperti 2.
In most cases, the field will have a sensible default widget. For example, by\ndefault, a CharField will have a TextInput widget, that\nproduces an <input type="text"> in the HTML. If you needed <textarea>\ninstead, you'd specify the appropriate widget when defining your form field,\nas we have done for the message field.
Whatever the data submitted with a form, once it has been successfully\nvalidated by calling is_valid() (and is_valid() has returned True),\nthe validated form data will be in the form.cleaned_data dictionary. This\ndata will have been nicely converted into Python types for you.
In the contact form example above, cc_myself will be a boolean value.\nLikewise, fields such as IntegerField and FloatField convert\nvalues to a Python int and float respectively.
Ini adalah bagaimana formulir dapat dapat diolah dalam tampilan yang menangani formulir ini:
\nviews.pyfrom django.core.mail import send_mail\n\nif form.is_valid():\n subject = form.cleaned_data['subject']\n message = form.cleaned_data['message']\n sender = form.cleaned_data['sender']\n cc_myself = form.cleaned_data['cc_myself']\n\n recipients = ['info@example.com']\n if cc_myself:\n recipients.append(sender)\n\n send_mail(subject, message, sender, recipients)\n return HttpResponseRedirect('/thanks/')\nSome field types need some extra handling. For example, files that are uploaded\nusing a form need to be handled differently (they can be retrieved from\nrequest.FILES, rather than request.POST). For details of how to handle\nfile uploads with your form, see Mengikat berkas terunggah ke formulir.
All you need to do to get your form into a template is to place the form\ninstance into the template context. So if your form is called form in the\ncontext, {{ form }} will render its <label> and <input> elements\nappropriately.
Ada pilihan keluaran lain meskipun untuk pasangan 1/2:
{{ form.as_table }} akan membangun mereka sebagai sel tabel terbungkus dalam etiket <tr>
{{ form.as_p }} akan membangun mereka terbungkus dalam etiket <p>
{{ form.as_ul }} akan membangun mereka terbungkus dalam etiket <li>
Catat bahwa anda harus menyediakan sekitarnya unsur 1 atau 2 anda sendiri.
Ini adalah keluaran dari {{ form.as_p }} untuk instance ContactForm kami:
<p><label for="id_subject">Subject:</label>\n <input id="id_subject" type="text" name="subject" maxlength="100" required></p>\n<p><label for="id_message">Message:</label>\n <textarea name="message" id="id_message" required></textarea></p>\n<p><label for="id_sender">Sender:</label>\n <input type="email" name="sender" id="id_sender" required></p>\n<p><label for="id_cc_myself">Cc myself:</label>\n <input type="checkbox" name="cc_myself" id="id_cc_myself"></p>\nNote that each form field has an ID attribute set to id_<field-name>, which\nis referenced by the accompanying label tag. This is important in ensuring that\nforms are accessible to assistive technology such as screen reader software.\nYou can also customize the way in which labels and ids are generated.
Lihat Mengeluarkan formulir sebagai HTML untuk lebih pada ini.
\nWe don't have to let Django unpack the form's fields; we can do it manually if\nwe like (allowing us to reorder the fields, for example). Each field is\navailable as an attribute of the form using {{ form.name_of_field }}, and\nin a Django template, will be rendered appropriately. For example:
{{ form.non_field_errors }}\n<div class="fieldWrapper">\n {{ form.subject.errors }}\n <label for="{{ form.subject.id_for_label }}">Email subject:</label>\n {{ form.subject }}\n</div>\n<div class="fieldWrapper">\n {{ form.message.errors }}\n <label for="{{ form.message.id_for_label }}">Your message:</label>\n {{ form.message }}\n</div>\n<div class="fieldWrapper">\n {{ form.sender.errors }}\n <label for="{{ form.sender.id_for_label }}">Your email address:</label>\n {{ form.sender }}\n</div>\n<div class="fieldWrapper">\n {{ form.cc_myself.errors }}\n <label for="{{ form.cc_myself.id_for_label }}">CC yourself?</label>\n {{ form.cc_myself }}\n</div>\nComplete <label> elements can also be generated using the\nlabel_tag(). For example:
<div class="fieldWrapper">\n {{ form.subject.errors }}\n {{ form.subject.label_tag }}\n {{ form.subject }}\n</div>\nThe price of this flexibility is a bit more work. Until now we haven't had to\nworry about how to display form errors, because that's taken care of for us. In\nthis example we have had to make sure we take care of any errors for each field\nand any errors for the form as a whole. Note {{ form.non_field_errors }} at\nthe top of the form and the template lookup for errors on each field.
Using {{ form.name_of_field.errors }} displays a list of form errors,\nrendered as an unordered list. This might look like:
<ul class="errorlist">\n <li>Sender is required.</li>\n</ul>\nThe list has a CSS class of errorlist to allow you to style its appearance.\nIf you wish to further customize the display of errors you can do so by looping\nover them:
{% if form.subject.errors %}\n <ol>\n {% for error in form.subject.errors %}\n <li><strong>{{ error|escape }}</strong></li>\n {% endfor %}\n </ol>\n{% endif %}\nNon-field errors (and/or hidden field errors that are rendered at the top of\nthe form when using helpers like form.as_p()) will be rendered with an\nadditional class of nonfield to help distinguish them from field-specific\nerrors. For example, {{ form.non_field_errors }} would look like:
<ul class="errorlist nonfield">\n <li>Generic validation error</li>\n</ul>\nLihat API Formulir untuk lebih pada kesalahan, gaya, dan bekerja dengan atribut formulir dalam cetakan-cetakan.
\nJika anda sedang menggunakan HTML sama untuk setiap bidang formulir anda, anda dapat mengurangi kode ganda dengan memutari setiap bidang bergantian menggunakan putaran {% for %}:
{% for field in form %}\n <div class="fieldWrapper">\n {{ field.errors }}\n {{ field.label_tag }} {{ field }}\n {% if field.help_text %}\n <p class="help">{{ field.help_text|safe }}</p>\n {% endif %}\n </div>\n{% endfor %}\nAtribut berguna pada {{ field }} termasuk:
{{ field.label }}Label dari bidang, sebagai contoh Alamat surel.
{{ field.label_tag }}The field's label wrapped in the appropriate HTML <label> tag. This\nincludes the form's label_suffix. For example,\nthe default label_suffix is a colon:
<label for="id_email">Email address:</label>\n{{ field.id_for_label }}ID yang akan digunakan untuk bidang ini (id_email di contoh diatas). Jika anda sedang membangun label secara manual, anda mungkin ingin menggunakan ini sebagai pengganti label_tag. Itu juga sangat berguna, sebagai contoh, jika anda mempunyai beberapa JavaScript berderet dan ingin menghindari kode keras ID bidang.
{{ field.value }}Nilai bidang sebagai contoh someone@example.com.
{{ field.html_name }}The name of the field that will be used in the input element's name\nfield. This takes the form prefix into account, if it has been set.
\n{{ field.help_text }}Teks bantuan apapun yang telah dikaitkan dengan bidang.
\n{{ field.errors }}Outputs a <ul class="errorlist"> containing any validation errors\ncorresponding to this field. You can customize the presentation of\nthe errors with a {% for error in field.errors %} loop. In this\ncase, each object in the loop is a string containing the error message.
{{ field.is_hidden }}This attribute is True if the form field is a hidden field and\nFalse otherwise. It's not particularly useful as a template\nvariable, but could be useful in conditional tests such as:
{% if field.is_hidden %}\n {# Do something special #}\n{% endif %}\n{{ field.field }}The Field instance from the form class that\nthis BoundField wraps. You can use it to access\nField attributes, e.g.\n{{ char_field.field.max_length }}.
If your site uses the same rendering logic for forms in multiple places, you\ncan reduce duplication by saving the form's loop in a standalone template and\nusing the include tag to reuse it in other templates:
# In your form template:\n{% include "form_snippet.html" %}\n\n# In form_snippet.html:\n{% for field in form %}\n <div class="fieldWrapper">\n {{ field.errors }}\n {{ field.label_tag }} {{ field }}\n </div>\n{% endfor %}\nIf the form object passed to a template has a different name within the\ncontext, you can alias it using the with argument of the include\ntag:
{% include "form_snippet.html" with form=comment_form %}\nJika anda menemukan diri anda melakukan ini sering, anda mungkin mempertimbangkan membuat penyesuaian inclusion tag1.
\nIni mencangkup dasar, tetapi formulir dapat melakukan keseluruhan lebih banyak:
\nMedia)\n