Anonymous user
Django for Designers: Difference between revisions
→Introduction to databases and the ORM, or: finally, something we couldn't've done with plain HTML/CSS/JS!
imported>Paulproteus (→Static files: Add a note that I think we should 'move' not 'copy' the files) |
imported>Paulproteus |
||
Line 712:
One key thing that separates web ''apps'' from web ''pages'' is that apps typically store data somewhere. The code that runs the app chooses what data seems most important to show at the moment. When writing an app using Django, we configure the storage through Django ''models''.
Every Django app comes with a ''models.py'' in which you list each kind of data you want to store. These are configured through Python classes (to name the kind of data) with a sequence of attributes (which control the pieces of data that make up the model). If you're familiar with, or interested in, SQL, these correspond to ''tables'' and ''columns'' respectively.
The models that you define here are built on top of Django's ''object-relational mapper'', or ORM. Because you define your models as ''objects'', you can effectively write queries against a ''relational'' database by writing code in Python that refers to your objects. Django then ''maps'' your Python code into relational database queries in SQL.
By configuring your data access in Python, Django makes it easy to take advantage of your data layout in other places. For example, you'll see later how the ORM makes it easy to automatically generate forms that ask for exactly the information you need. It is also generally convenient to write your entire app in one language, rather than being required to switch to SQL to do queries. The ORM also handles "escaping," which makes your SQL queries handle Unicode and other strange characters properly. These conveniences let you avoid [http://en.wikipedia.org/wiki/Mojibake mojibake]-style data corruption and [http://en.wikipedia.org/wiki/SQL_injection SQL injection] attacks effortlessly.
TODO (models.py --> ORM --> DB chart)
| |||