As far as I understand, you could certainly implement the same
functionality in a view using newforms to validate the input. To do it
in the model, something like the patch suggested in the ticket or the
approach linked to at the end of the comments on that ticket would be
needed. The code here shows the crucial ingredient:
def get_limit_choices_to(self):
limiters = {}
if self.limit_choices_to:
for id in self.limit_choices_to:
value = self.limit_choices_to[id]
if callable(value):
value = value()
limiters[id] = value
return limiters
The check for whether limit_choices_to is a callable() is what you
need: the ability to have limit_choices_to evaluated at runtime rather
than just an array stuck into the model that is checked against. If
you look into the Django model API documentation example that uses
models.LazyDate() and do some hunting around code.djangoproject.com
for discussion about LazyDate, you'll see that people have done some
pretty odd things to delay the checking of limit_choices_to until the
model class is actually instantiated.
IN SHORT: ;-) the get_assigned_tasks_id_list(blah, blah) is just a
stand in for whatever code you might want to run when the model is
instantiated to check what should allowed as input.
On Jan 29, 1:57 pm, "qhfgva" <[EMAIL PROTECTED]> wrote:
> Thanks for the response. I'm not sure if this exactly covers my case
> but I like this feature. From the example given in the ticket:
>
> def assigned_tasks():
> return get_assigned_tasks_id_list(blah, blah)
>
> class TimeRecord(models.Model):
> task = models.ForeignKey(Task, limit_choices_to = {'id__in':
> assigned_tasks})
>
> I would like the assigned_tasks function to be have a reference to and
> be able to calculate values based on the current instance of
> TimeRecord. Perhaps that is what blah or blah are but I'm guessing
> not.
>
> Do I need to do something like work directly with newforms to achieve
> something like this?
>
> On Jan 29, 6:54 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
>
> > See patch on ticket <http://code.djangoproject.com/ticket/2445>.
>
> > On Jan 29, 8:31 am, "qhfgva" <[EMAIL PROTECTED]> wrote:
>
> > > If my original post was not entirely clear, I'm interested in any
> > > method available to limit_choices_to that lets you dynamically create
> > > the list of available options as a function of the current model
> > > instance.
>
> > > thanks.
>
> > > On Jan 28, 4:28 pm, "qhfgva" <[EMAIL PROTECTED]> wrote:
>
> > > > I currently have a drop down for a model where I'd only like to show
> > > > choices that are currently "active". That's easy enough with:
>
> > > > foo = models.ForeignKey(Foo,
> > > > limit_choices_to={'active__exact':True})
>
> > > > But if someone is working with a model where the "foo" that they had
> > > > previously selected has been subsequently set to inactive they should
> > > > be able to keep that foo (they are "grandfathered" in).
>
> > > > In effect I'd like limit_choices_to to have a list of foo.active ==
> > > > True plus the current selection they have from the past if it is not
> > > > an active choice.
>
> > > > If I could make a method of Foo such as Foo.allowed_choice_for_x and
> > > > then pass it an instance of the current object, then it seems like I
> > > > could easily generate the specific drop downlist on the fly but I'm
> > > > not sure how to do that (or if it's possible).
>
> > > > Thoughts?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
