In terms of backward compatibility, perhaps there could be a new keyword argument to Field, something like with_model_defaults, that the user would use to indicate a desire to get the attributes from the Model. How would this work? Maybe something like this (this is just a sketch): Field.__init__() works the same way, except that it also stores the value of the keyword arguments (with_model_defaults, as well as the others, since the user should be able to override individual settings). Then ModelForm's metaclass will call a method on the field, passing in the field name. The field can then extract the default values from the Model and set itself up appropriately.
Too much trickery? Before looking into how Django works I would have definitely said yes, but now my standards have changed. :) (That's not a criticism, I'm very happy with the trickery Django implies to make life easier for the user.) > There's also a ticket waiting for check-in implementing this common > usecase:http://code.djangoproject.com/ticket/9223 Thanks, the accompanying discussion is very interesting and on point. But as someone there points out, why stop at widgets? The discussion strengthens my intuition that widgets, fields, and the attributes I'm discussing here are fairly orthogonal concepts, and the current all-or- nothing declarative syntax couples them too tightly. Both your solution and the (much less thought-out) one I just proposed feel too small to me, but I'm not sure of a better solution. Cheers, Kevin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
