On Mon, 2008-11-24 at 13:07 +0200, Donn wrote: > Further info, > Looks like from within a widget there's no easy way to find the Form. I'd a > thunk there'd be a Parent attribute, but there ain't.
The way Django does this is fairly normal design practice. Normal OO implementation practice is the hierarchical dependencies only go one way, not having references both "down" and "up". The widget is at the bottom of the hierarchy and is intentionally a fairly simple object. All it has to know how to do is render itself into HTML, given an initial value. The "smarts" of a field (e.g. validation) lie in the Field class and tying fields together to make an holistic form is the Form class (and above or next to that is the ModelForm class that knows how to make a form from a model). There's no need for a widget to know that something is a "model id", since widgets don't care about models or what an id is. All it wants to know is "what should I render?" However, one might want to pass the model id down as some kind of initial data to a field and thus to the widget for rendering. When designing these sorts of things, it often helps to remember that the same data "value" can move through a number of semantic roles: it's a model id at the ModelForm level, say, but by the time a Widget subclass is dealing with it, it's just initial data. Keeps things in perspective. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
