On Jan 22, 12:12 am, Jacob Kaplan-Moss <jacob.kaplanm...@gmail.com> wrote: > 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.
I could have been clearer. I'm not talking about Django Models here; I'm talking about models, views, and controllers from the Model- View-Controller design pattern. Django widgets would correspond to views, while Django forms would correspond to models. In the current architecture, this division is very muddled; I suggested reducing the interdependency and adding a FormRenderer class; that would allow the display elements (widgets) to be handled by a display controller (a form renderer) while the model elements (fields) were handled by a model controller (the form). > > 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" ... No, no. You're missing my point. I was responding to Russell, who said "A form contains fields ... Each field provides a widget, which describes a HTML element that allows that data to be collected." That description--that forms contain many fields, and each field corresponds to a widget--isn't sufficient to explain the relationship between forms, fields, and widgets. And it's a very limiting conception of what the form functionality ought to do for Django as well. > > 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) Yes, I know this. That's why I used it as an example. This is a case where the field gets asked, during the rendering process, "I'm drawing a PasswordInput, are there any extra attributes I should add?" and the field adds the input length to the HTML. I'm rather aghast that Fields are expected to know about HTML at all, let alone be aware of all the available widgets so they can modify them. A better design is to have the fields open to interrogation by widgets. That way, a widget can ask if there's a limit on the number of characters in this field. That way new widgets and new fields work together, without having to know about each other ahead of time. > 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? Very well. I'm trying to write a subclass of Form that knows about Dojo forms, and will render them appropriately. To do this, I assumed I would subclass Form (as DojoForm) and then create a widget for each Dojo form element I wanted to use. The DojoForm would have a number of settings relating to the form as a whole, which would alter the way each DojoWidget rendered itself. When a DojoForm gets passed to a template, I could then call a method in the head of the document that would know what statements to place in the Javascript, and a different method in the body of the document which would render the actual form proper. What's the best way of doing this? -- Chris --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
