On Tue, Mar 17, 2009 at 5:33 AM, NoviceSortOf <[email protected]>wrote:
> > Looking at the django document > ref-forms-api Brian mentioned above from > the python command line its clearly explicit > that data passed as form = FormClass(data) > only creates input fields. I get that but > what I don't get is why the same value passed in render_to_response is > passable as a string. (I hope that makes sense) > I'm having a hard time understanding your confusion here. Passing variables in the template context for display is the fundamental way to display variable data in your template. It's covered pretty early in the template documentation here: http://docs.djangoproject.com/en/dev/topics/templates/#variables That's step one. When you have some data, like a variable user's name, and you want to display a message like "Hello <whatever-user-this-happens-to-be>" in your template, you put a variable holding the name into the context (something like { 'fname': user.first_name }, and then in your template you put: Hello {{ fname }}. That works fine for display, and as described in the docs you can use variable.attribute in the template to access more than just the base variable, and the template engine will automatically try dictionary lookup, attribute lookup, method call, etc. on the variable to resolve whatever goes after the dot. So you can get fancier in what you display in the template than just the bare contents of whatever variable you have passed. But if you want to both display that variable and allow the user to possibly change it and feed it back as part of an html form, that's not so easy using just the bare bones of template variable handling. And that's why Django forms were created -- so that every Django user didn't have to re-write presenting variables as part of html forms in templates. A form passed to a template is just another variable, but one that happens to know how to render itself (that is, its constituent fields) as html input elements. Forms do a lot of nice things like put labels on your fields, handle basic type validation and provide hooks for you to specify your own field and form data validation, etc. They're meant for data that you want to present to the user as something that can be changed, not for simple display of data. Even if forms supported read-only fields, the display of a read-only field containing varible 'x' would be considerably different than the display of the same variable 'x' just passed through in the template context and rendered as {{ x }}. As part of a form, it would still have an associated label, and an html input element, it's just that the input element would be marked read-only or disabled so that the user couldn't change the value. So you wouldn't use a read-only form field to display something like the user's first name in a message "Hello <user>". That's not a case where you want anything that looks like a form or an html input element, you just want to display the variable value. So you pass it directly in the template. It seems like maybe you jumped right into learning about forms and missed the fundamental basics of learning about Django templates. Forms are a specific tool, you use them for displaying data you want to allow the user to change. Forms are not intended for basic data display, as that is handled much more simply by just passing variables directly to the template in the template context. Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
