I'll take a shot. On Mon, Mar 7, 2011 at 11:43 AM, yongzhen zhang <4...@live.cn> wrote: > Hi, > When i am doing some exercises, i found some questions are very to > understand, Could you tell me which sentiences are correct? > 1. Models convert data from relational database form to objects and > vice versa.
Somewhat true. Models define the data you want to persist in the database. In cahoots with the database back end code, they thus specify one or more tables per model (mostly one, but an occasional auxiliary table is sometimes used), and what the columns of the table(s) are, both as to data types and column names. It is the database back end code (shared by all models) that knows how to convert between database representation of data and the python objects you find in fields of *instances* of the model class. > 2. Django model has to be written for a specific relation database False. settings.py specifies which database (and database back end) you are using, and, generally speaking, the same model will work unmodified with, for example, sqlite and postresql. Some databases, however, have their quirks, and may restrict your model coding, but obeying those restrictions won't (in general) prevent the model from working with one of the more "regular" databases. (Database back ends for some of the less usual databases may have some warts of their own.) > 3. Foreignkey are used to refer to elements in the other databases False. Foreign keys reference rows in other tables or the same table in the same database. I think that some of the more recent work allows references to rows in tables in another database, but this is an uncommon need (single database projects are still the norm for most of us). > about the views: > > 4. they interpret user input contained in the HTTP requests The can interpret user input, in the form of GET and/or POST parameters, but many views do not. Mostly a view is code that decides what to return to the user (what he views). They may or may not use user input for this decision. > 5. they create the user interface Not, in general, by themselves. If you consider the url path design to be part of the user interface (as I do), then the url resolver and it's urls.py modules is involved. And while a view can return a response without using templates, that is unusual (other than for the return or errors or non-HTML content). > 6. they access the models They can access model data (instances of models), but they don't have to. It's perfectly reasonable to have a view that, for example, gives you information about the site and tells you the current time. But when database data needed to generate the response, then, yes, they obtain model instances to access that data (similarly, if they need to store something in the database). > about the templates: > > 7. Templates can specify any HTTP Headers for the response False. HTTP headers are set in the view. A normal template does not affect them (except by having an error exception). While it would be possible for a view to use the return value of some special template when it sets response headers, this is not common practice. Headers are though of a more in the programmer's province than in the presentation designer's. > The last thing is that why django has a mechanism to protects against > calling methods from template that have side effects is a good idea? Templates are supposed to be about presentation, that is, how the response looks. Logic generally belongs elsewhere, though the distinction is hard to draw, leading to "if" and "for" constructs in templates. Most logic is better expressed in python than in the template language. Expressing complex logic in the template language is torturous. In serious projects template coding is often handled by separate people, whose expertise is visual design and how to get things to look right in IE6, but who are not necessarily programmers. This separation is accepted by many (most?) as modern good practice, even if the programmer and template designer are the same person (you should be in different frames of mind for the two tasks). That being said, django does not prevent your template from having side effects. You just need the cooperation of your view and/or models and/or write a template tag or filter. Bill -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
