On Thu, Jan 22, 2009 at 4:57 PM, catsclaw <ch...@subtlety.com> wrote: > Well, it seems to me that makes for an *extremely* tight coupling > between the model and the view.
I'm sorry to be so blunt, but your perception is misguided. Forms have no dependancy upon models, nor do models on forms, nor must views use forms, models, or anything, really. *Model*Forms do of course have dependancies on both, but you can use a form without using models at all. I have Django apps in the wild that have no database connection, and I use forms just fine. I really think you need to do more research here. Maybe if you share exactly what you're trying to do we can help figure out why it seems so hard. > And it's a little difficult for me to > understand what value there is in such a tight coupling--if I've got a > DateField, why can't I have it represented in an HTML page by a > javascript calendar pop-up, or a text box, or three select boxes > (month, day, and year). It's difficult to understand because you've assumed it's impossible; it's not. A quick google search for "django datefield select" turns up http://www.djangosnippets.org/snippets/399/ as the first result; there's a few other recipes showing similar widgets. Using custom widgets is in fact incredibly easy. Start by reading http://docs.djangoproject.com/en/dev/ref/forms/widgets/#specifying-widgets, and follow on from there. > Plus, any time you collect a password you need to display it in a > form using a password input, not the stock text input. Again, this is in fact not only possible, but easy:: class MyForm(forms.Form): password = forms.CharField(widget=forms.PasswordInput) > And I might > very well have two separate form fields which should be displayed as a > single unit. This one's our fault: ``forms.ComboForm`` is what you want here, but it's not yet documented. Sorry! > There's a need to have the display decoupled from the > form logic. Django just doesn't provide much help in doing that. It's pretty decoupled. If you want a custom widget, write a custom ``Widget``. > In other words, if I create a > widget which renders a CharField and I'd like to validate the maximum > length, I either *must* inherit from TextInput or PasswordInput, edit > the CharField class, or write a different CharField class that's aware > of my new widget. No, you don't:: class MyForm(forms.Form): password = forms.CharField(widget=forms.PasswordInput, max_length=30) > If I were writing it, I'd make the Form class responsible for > defining the order of the fields, the labels, the validation logic and > errors. The Fields would be part of that. You just described exactly how Django's form package works. Seriously. The ``Form`` defines the order of fields (they're sorted in definition order), the validation logic (in the form of ``clean_*`` methods), and errors (as ``Form.errors``). --------- Why don't we start over here: what is the problem? What did you try do do? What did you expect to happen? What actually happened? Jacob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
