标签归档:Django

Django将自定义表单参数传递给Formset

问题:Django将自定义表单参数传递给Formset

这在Django 1.9中用form_kwargs修复

我有一个看起来像这样的Django表单:

class ServiceForm(forms.Form):
    option = forms.ModelChoiceField(queryset=ServiceOption.objects.none())
    rate = forms.DecimalField(widget=custom_widgets.SmallField())
    units = forms.IntegerField(min_value=1, widget=custom_widgets.SmallField())

    def __init__(self, *args, **kwargs):
        affiliate = kwargs.pop('affiliate')
        super(ServiceForm, self).__init__(*args, **kwargs)
        self.fields["option"].queryset = ServiceOption.objects.filter(affiliate=affiliate)

我称这种形式是这样的:

form = ServiceForm(affiliate=request.affiliate)

request.affiliate登录用户在哪里。这按预期工作。

我的问题是我现在想将此单一表单转换为表单集。我不知道的是在创建表单集时如何将会员信息传递给各个表单。根据文档来制作一个表单集,我需要做这样的事情:

ServiceFormSet = forms.formsets.formset_factory(ServiceForm, extra=3)

然后我需要这样创建它:

formset = ServiceFormSet()

现在如何以这种方式将affiliate = request.affiliate传递给各个表单?

This was fixed in Django 1.9 with form_kwargs.

I have a Django Form that looks like this:

class ServiceForm(forms.Form):
    option = forms.ModelChoiceField(queryset=ServiceOption.objects.none())
    rate = forms.DecimalField(widget=custom_widgets.SmallField())
    units = forms.IntegerField(min_value=1, widget=custom_widgets.SmallField())

    def __init__(self, *args, **kwargs):
        affiliate = kwargs.pop('affiliate')
        super(ServiceForm, self).__init__(*args, **kwargs)
        self.fields["option"].queryset = ServiceOption.objects.filter(affiliate=affiliate)

I call this form with something like this:

form = ServiceForm(affiliate=request.affiliate)

Where request.affiliate is the logged in user. This works as intended.

My problem is that I now want to turn this single form into a formset. What I can’t figure out is how I can pass the affiliate information to the individual forms when creating the formset. According to the docs to make a formset out of this I need to do something like this:

ServiceFormSet = forms.formsets.formset_factory(ServiceForm, extra=3)

And then I need to create it like this:

formset = ServiceFormSet()

Now how can I pass affiliate=request.affiliate to the individual forms this way?


回答 0

我会用functools.partialfunctools.wraps

from functools import partial, wraps
from django.forms.formsets import formset_factory

ServiceFormSet = formset_factory(wraps(ServiceForm)(partial(ServiceForm, affiliate=request.affiliate)), extra=3)

我认为这是最干净的方法,并且不会以任何方式影响ServiceForm(即,使子类难以继承)。

I would use functools.partial and functools.wraps:

from functools import partial, wraps
from django.forms.formsets import formset_factory

ServiceFormSet = formset_factory(wraps(ServiceForm)(partial(ServiceForm, affiliate=request.affiliate)), extra=3)

I think this is the cleanest approach, and doesn’t affect ServiceForm in any way (i.e. by making it difficult to subclass).


回答 1

正式文件方式

Django 2.0:

ArticleFormSet = formset_factory(MyArticleForm)
formset = ArticleFormSet(form_kwargs={'user': request.user})

https://docs.djangoproject.com/zh-CN/2.0/topics/forms/formsets/#passing-custom-parameters-to-formset-forms

Official Document Way

Django 2.0:

ArticleFormSet = formset_factory(MyArticleForm)
formset = ArticleFormSet(form_kwargs={'user': request.user})

https://docs.djangoproject.com/en/2.0/topics/forms/formsets/#passing-custom-parameters-to-formset-forms


回答 2

我将在一个函数中动态构建表单类,以便它可以通过闭包访问关联:

def make_service_form(affiliate):
    class ServiceForm(forms.Form):
        option = forms.ModelChoiceField(
                queryset=ServiceOption.objects.filter(affiliate=affiliate))
        rate = forms.DecimalField(widget=custom_widgets.SmallField())
        units = forms.IntegerField(min_value=1, 
                widget=custom_widgets.SmallField())
    return ServiceForm

另外,您不必在选项字段中重写查询集。缺点是子类化有点时髦。(任何子类都必须以类似的方式创建。)

编辑:

为了回应评论,您可以在使用类名的任何地方调用此函数:

def view(request):
    affiliate = get_object_or_404(id=request.GET.get('id'))
    formset_cls = formset_factory(make_service_form(affiliate))
    formset = formset_cls(request.POST)
    ...

I would build the form class dynamically in a function, so that it has access to the affiliate via closure:

def make_service_form(affiliate):
    class ServiceForm(forms.Form):
        option = forms.ModelChoiceField(
                queryset=ServiceOption.objects.filter(affiliate=affiliate))
        rate = forms.DecimalField(widget=custom_widgets.SmallField())
        units = forms.IntegerField(min_value=1, 
                widget=custom_widgets.SmallField())
    return ServiceForm

As a bonus, you don’t have to rewrite the queryset in the option field. The downside is that subclassing is a little funky. (Any subclass has to be made in a similar way.)

edit:

In response to a comment, you can call this function about any place you would use the class name:

def view(request):
    affiliate = get_object_or_404(id=request.GET.get('id'))
    formset_cls = formset_factory(make_service_form(affiliate))
    formset = formset_cls(request.POST)
    ...

回答 3

这是对我有效的Django 1.7:

from django.utils.functional import curry    

lols = {'lols':'lols'}
formset = modelformset_factory(MyModel, form=myForm, extra=0)
formset.form = staticmethod(curry(MyForm, lols=lols))
return formset

#form.py
class MyForm(forms.ModelForm):

    def __init__(self, lols, *args, **kwargs):

希望它能对某人有所帮助,花了我足够长的时间才能弄清楚;)

This is what worked for me, Django 1.7:

from django.utils.functional import curry    

lols = {'lols':'lols'}
formset = modelformset_factory(MyModel, form=myForm, extra=0)
formset.form = staticmethod(curry(MyForm, lols=lols))
return formset

#form.py
class MyForm(forms.ModelForm):

    def __init__(self, lols, *args, **kwargs):

Hope it helps someone, took me long enough to figure it out ;)


回答 4

我喜欢闭包解决方案,因为它更“干净”,并且使用了更多的Python语言(因此对+1表示响应),但Django表单也具有可用于过滤表单集中的查询集的回调机制。

它也没有记录,我认为这表明Django开发人员可能不太喜欢它。

因此,您基本上创建了相同的表单集,但添加了回调:

ServiceFormSet = forms.formsets.formset_factory(
    ServiceForm, extra=3, formfield_callback=Callback('option', affiliate).cb)

这将创建一个如下所示的类的实例:

class Callback(object):
    def __init__(self, field_name, aff):
        self._field_name = field_name
        self._aff = aff
    def cb(self, field, **kwargs):
        nf = field.formfield(**kwargs)
        if field.name == self._field_name:  # this is 'options' field
            nf.queryset = ServiceOption.objects.filter(affiliate=self._aff)
        return nf

这应该给您大致的想法。使回调成为这样的对象方法要稍微复杂一些,但是与执行简单的函数回调相比,它具有更多的灵活性。

I like the closure solution for being “cleaner” and more Pythonic (so +1 to mmarshall answer) but Django forms also have a callback mechanism you can use for filtering querysets in formsets.

It’s also not documented, which I think is an indicator the Django devs might not like it as much.

So you basically create your formset the same but add the callback:

ServiceFormSet = forms.formsets.formset_factory(
    ServiceForm, extra=3, formfield_callback=Callback('option', affiliate).cb)

This is creating an instance of a class that looks like this:

class Callback(object):
    def __init__(self, field_name, aff):
        self._field_name = field_name
        self._aff = aff
    def cb(self, field, **kwargs):
        nf = field.formfield(**kwargs)
        if field.name == self._field_name:  # this is 'options' field
            nf.queryset = ServiceOption.objects.filter(affiliate=self._aff)
        return nf

This should give you the general idea. It’s a little more complex making the callback an object method like this, but gives you a little more flexibility as opposed to doing a simple function callback.


回答 5

我想将其作为对卡尔·迈耶斯答案的评论,但由于这需要要点,因此我将其放在此处。我花了2个小时才弄清楚,所以希望对您有所帮助。

有关使用inlineformset_factory的注释。

我自己使用了该解决方案,并且效果很好,直到我使用inlineformset_factory对其进行了尝试。我正在运行Django 1.0.2,并遇到了一些奇怪的KeyError异常。我升级到最新的后备箱,并且可以直接使用。

我现在可以像这样使用它:

BookFormSet = inlineformset_factory(Author, Book, form=BookForm)
BookFormSet.form = staticmethod(curry(BookForm, user=request.user))

I wanted to place this as a comment to Carl Meyers answer, but since that requires points I just placed it here. This took me 2 hours to figure out so I hope it will help someone.

A note about using the inlineformset_factory.

I used that solution my self and it worked perfect, until I tried it with the inlineformset_factory. I was running Django 1.0.2 and got some strange KeyError exception. I upgraded to latest trunk and it worked direct.

I can now use it similar to this:

BookFormSet = inlineformset_factory(Author, Book, form=BookForm)
BookFormSet.form = staticmethod(curry(BookForm, user=request.user))

回答 6

从2012年8月14日星期二23:44:46 +0200提交e091c18f50266097f648efc7cac2503968e9d217开始,已接受的解决方案不再起作用。

当前版本的django.forms.models.modelform_factory()函数使用“类型构造技术”,在传递的表单上调用type()函数以获取元类类型,然后使用结果来构造其类对象即时输入::

# Instatiate type(form) in order to use the same metaclass as form.
return type(form)(class_name, (form,), form_class_attrs)

这意味着即使是一个curryed或partial对象,而不是一种形式的传递,也可以说是“导致鸭子咬你”:它会使用ModelFormClass对象的构造参数调用函数,并返回错误消息:

function() argument 1 must be code, not str

为了解决这个问题,我编写了一个生成器函数,该函数使用闭包返回指定为第一个参数的任何类的子类,然后在使用生成器函数的调用中提供的kwargs进行调用super.__init__之后update调用:

def class_gen_with_kwarg(cls, **additionalkwargs):
  """class generator for subclasses with additional 'stored' parameters (in a closure)
     This is required to use a formset_factory with a form that need additional 
     initialization parameters (see http://stackoverflow.com/questions/622982/django-passing-custom-form-parameters-to-formset)
  """
  class ClassWithKwargs(cls):
      def __init__(self, *args, **kwargs):
          kwargs.update(additionalkwargs)
          super(ClassWithKwargs, self).__init__(*args, **kwargs)
  return ClassWithKwargs

然后在您的代码中将表单工厂称为::

MyFormSet = inlineformset_factory(ParentModel, Model,form = class_gen_with_kwarg(MyForm, user=self.request.user))

注意事项:

  • 至少到目前为止,这很少接受测试
  • 提供的参数可能会冲突并覆盖那些将使用构造函数返回的对象的代码所使用的参数

As of commit e091c18f50266097f648efc7cac2503968e9d217 on Tue Aug 14 23:44:46 2012 +0200 the accepted solution can’t work anymore.

The current version of django.forms.models.modelform_factory() function uses a “type construction technique”, calling the type() function on the passed form to get the metaclass type, then using the result to construct a class-object of its type on the fly::

# Instatiate type(form) in order to use the same metaclass as form.
return type(form)(class_name, (form,), form_class_attrs)

This means even a curryed or partial object passed instead of a form “causes the duck to bite you” so to speak: it’ll call a function with the construction parameters of a ModelFormClass object, returning the error message::

function() argument 1 must be code, not str

To work around this I wrote a generator function that uses a closure to return a subclass of any class specified as first parameter, that then calls super.__init__ after updateing the kwargs with the ones supplied on the generator function’s call::

def class_gen_with_kwarg(cls, **additionalkwargs):
  """class generator for subclasses with additional 'stored' parameters (in a closure)
     This is required to use a formset_factory with a form that need additional 
     initialization parameters (see http://stackoverflow.com/questions/622982/django-passing-custom-form-parameters-to-formset)
  """
  class ClassWithKwargs(cls):
      def __init__(self, *args, **kwargs):
          kwargs.update(additionalkwargs)
          super(ClassWithKwargs, self).__init__(*args, **kwargs)
  return ClassWithKwargs

Then in your code you’ll call the form factory as::

MyFormSet = inlineformset_factory(ParentModel, Model,form = class_gen_with_kwarg(MyForm, user=self.request.user))

caveats:

  • this received very little testing, at least for now
  • supplied parameters could clash and overwrite those used by whatever code will use the object returned by the constructor

回答 7

卡尔·迈耶的解决方案看起来非常优雅。我尝试为modelformsets实现它。我的印象是我无法在类中调用静态方法,但是以下操作莫名其妙地起作用:

class MyModel(models.Model):
  myField = models.CharField(max_length=10)

class MyForm(ModelForm):
  _request = None
  class Meta:
    model = MyModel

    def __init__(self,*args,**kwargs):      
      self._request = kwargs.pop('request', None)
      super(MyForm,self).__init__(*args,**kwargs)

class MyFormsetBase(BaseModelFormSet):
  _request = None

def __init__(self,*args,**kwargs):
  self._request = kwargs.pop('request', None)
  subFormClass = self.form
  self.form = curry(subFormClass,request=self._request)
  super(MyFormsetBase,self).__init__(*args,**kwargs)

MyFormset =  modelformset_factory(MyModel,formset=MyFormsetBase,extra=1,max_num=10,can_delete=True)
MyFormset.form = staticmethod(curry(MyForm,request=MyFormsetBase._request))

在我看来,如果我做这样的事情:

formset = MyFormset(request.POST,queryset=MyModel.objects.all(),request=request)

然后,“ request”关键字传播到我的表单集中的所有成员表单。我很高兴,但我不知道为什么这样做有效-似乎错了。有什么建议?

Carl Meyer’s solution looks very elegant. I tried implementing it for modelformsets. I was under the impression that I could not call staticmethods within a class, but the following inexplicably works:

class MyModel(models.Model):
  myField = models.CharField(max_length=10)

class MyForm(ModelForm):
  _request = None
  class Meta:
    model = MyModel

    def __init__(self,*args,**kwargs):      
      self._request = kwargs.pop('request', None)
      super(MyForm,self).__init__(*args,**kwargs)

class MyFormsetBase(BaseModelFormSet):
  _request = None

def __init__(self,*args,**kwargs):
  self._request = kwargs.pop('request', None)
  subFormClass = self.form
  self.form = curry(subFormClass,request=self._request)
  super(MyFormsetBase,self).__init__(*args,**kwargs)

MyFormset =  modelformset_factory(MyModel,formset=MyFormsetBase,extra=1,max_num=10,can_delete=True)
MyFormset.form = staticmethod(curry(MyForm,request=MyFormsetBase._request))

In my view, if I do something like this:

formset = MyFormset(request.POST,queryset=MyModel.objects.all(),request=request)

Then the “request” keyword gets propagated to all of the member forms of my formset. I’m pleased, but I have no idea why this is working – it seems wrong. Any suggestions?


回答 8

在看到这篇文章之前,我花了一些时间试图解决这个问题。

我想到的解决方案是闭包解决方案(这是我之前在Django模型表单中使用的解决方案)。

我如上所述尝试了curry()方法,但是我无法使它与Django 1.0一起使用,因此最终我恢复为闭包方法。

闭合方法非常简洁,唯一的奇怪之处是类定义嵌套在视图或其他函数中。我认为这对我来说似乎很奇怪,这是我以前的编程经验的遗忘,而且我认为具有动态语言背景的人也不会蒙上双眼!

I spent some time trying to figure out this problem before I saw this posting.

The solution I came up with was the closure solution (and it is a solution I’ve used before with Django model forms).

I tried the curry() method as described above, but I just couldn’t get it to work with Django 1.0 so in the end I reverted to the closure method.

The closure method is very neat and the only slight oddness is that the class definition is nested inside the view or another function. I think the fact that this looks odd to me is a hangup from my previous programming experience and I think someone with a background in more dynamic languages wouldn’t bat an eyelid!


回答 9

我不得不做类似的事情。这类似于curry解决方案:

def form_with_my_variable(myvar):
   class MyForm(ServiceForm):
     def __init__(self, myvar=myvar, *args, **kwargs):
       super(SeriveForm, self).__init__(myvar=myvar, *args, **kwargs)
   return MyForm

factory = inlineformset_factory(..., form=form_with_my_variable(myvar), ... )

I had to do a similar thing. This is similar to the curry solution:

def form_with_my_variable(myvar):
   class MyForm(ServiceForm):
     def __init__(self, myvar=myvar, *args, **kwargs):
       super(SeriveForm, self).__init__(myvar=myvar, *args, **kwargs)
   return MyForm

factory = inlineformset_factory(..., form=form_with_my_variable(myvar), ... )

回答 10

基于此答案,我找到了更清晰的解决方案:

class ServiceForm(forms.Form):
    option = forms.ModelChoiceField(
            queryset=ServiceOption.objects.filter(affiliate=self.affiliate))
    rate = forms.DecimalField(widget=custom_widgets.SmallField())
    units = forms.IntegerField(min_value=1, 
            widget=custom_widgets.SmallField())

    @staticmethod
    def make_service_form(affiliate):
        self.affiliate = affiliate
        return ServiceForm

并像这样运行它

formset_factory(form=ServiceForm.make_service_form(affiliate))

based on this answer I found more clear solution:

class ServiceForm(forms.Form):
    option = forms.ModelChoiceField(
            queryset=ServiceOption.objects.filter(affiliate=self.affiliate))
    rate = forms.DecimalField(widget=custom_widgets.SmallField())
    units = forms.IntegerField(min_value=1, 
            widget=custom_widgets.SmallField())

    @staticmethod
    def make_service_form(affiliate):
        self.affiliate = affiliate
        return ServiceForm

And run it in view like

formset_factory(form=ServiceForm.make_service_form(affiliate))

回答 11

我是这里的新手,因此无法添加评论。我希望这段代码也能工作:

ServiceFormSet = formset_factory(ServiceForm, extra=3)

ServiceFormSet.formset = staticmethod(curry(ServiceForm, affiliate=request.affiliate))

至于向BaseFormSet表单集(而不是表单)添加其他参数。

I’m a newbie here so I can’t add comment. I hope this code will work too:

ServiceFormSet = formset_factory(ServiceForm, extra=3)

ServiceFormSet.formset = staticmethod(curry(ServiceForm, affiliate=request.affiliate))

as for adding additional parameters to the formset’s BaseFormSet instead of form.


django的model.save()为什么不调用full_clean()?

问题:django的model.save()为什么不调用full_clean()?

我只是好奇是否有人知道,除非有理由将django的orm不保存在模型中,否则它不会在模型上调用“ full_clean”。

请注意,当您调用模型的save()方法时,不会自动调用full_clean()。若要为自己创建的模型运行一步模型验证,则需要手动调用它。 django的完整档案

(注意:报价已针对Django 1.6更新…之前的django文档也对ModelForms提出了警告。)

人们为什么不希望这种行为有充分的理由?我想如果您花时间向模型添加验证,则希望每次保存模型时都运行验证。

我知道如何使一切正常工作,我只是在寻找一种解释。

I’m just curious if anyone knows if there’s good reason why django’s orm doesn’t call ‘full_clean’ on a model unless it is being saved as part of a model form.

Note that full_clean() will not be called automatically when you call your model’s save() method. You’ll need to call it manually when you want to run one-step model validation for your own manually created models. django’s full clean doc

(NOTE: quote updated for Django 1.6… previous django docs had a caveat about ModelForms as well.)

Are there good reasons why people wouldn’t want this behavior? I’d think if you took the time to add validation to a model, you’d want that validation run every time the model is saved.

I know how to get everything to work properly, I’m just looking for an explanation.


回答 0

AFAIK,这是因为向后兼容。带有排除字段的ModelForms,具有默认值的模型,pre_save()信号等也存在问题。

您可能感兴趣的资源:

AFAIK, this is because of backwards compatibility. There are also problems with ModelForms with excluded fields, models with default values, pre_save() signals, etc.

Sources you might be intrested in:


回答 1

由于考虑到兼容性,因此在django内核中未启用保存时自动清除。

如果我们正在启动一个新项目,并且希望saveModel上的默认方法可以自动清除,则可以在保存每个模型之前使用以下信号进行清除。

from django.dispatch import receiver
from django.db.models.signals import pre_save, post_save

@receiver(pre_save)
def pre_save_handler(sender, instance, *args, **kwargs):
    instance.full_clean()

Because of the compatibility considering, the auto clean on save is not enabled in django kernel.

If we are starting a new project and want the default save method on Model could clean automatically, we can use the following signal to do clean before every model was saved.

from django.dispatch import receiver
from django.db.models.signals import pre_save, post_save

@receiver(pre_save)
def pre_save_handler(sender, instance, *args, **kwargs):
    instance.full_clean()

回答 2

调用该full_clean方法的最简单方法是save在您的方法中覆盖该方法model

def save(self, *args, **kwargs):
    self.full_clean()
    return super(YourModel, self).save(*args, **kwargs)

The simpliest way to call the full_clean method is just to override save method in your model:

def save(self, *args, **kwargs):
    self.full_clean()
    return super(YourModel, self).save(*args, **kwargs)

回答 3

除了插入件的代码,声明了一个接收器的,我们可以使用一个应用程序如INSTALLED_APPS在节settings.py

INSTALLED_APPS = [
    # ...
    'django_fullclean',
    # your apps here,
]

在此之前,您可能需要django-fullclean使用PyPI 安装:

pip install django-fullclean

Instead of inserting a piece of code that declares a receiver, we can use an app as INSTALLED_APPS section in settings.py

INSTALLED_APPS = [
    # ...
    'django_fullclean',
    # your apps here,
]

Before that, you may need to install django-fullclean using PyPI:

pip install django-fullclean

回答 4

如果您要确保具有至少一个FK关系的模型,并且不想使用该模型,null=False因为这需要设置默认FK(这将是垃圾数据),那么我想出的最好方法是添加自定义.clean().save()方法。.clean()引发验证错误,并.save()调用clean。这样,可以从表单以及其他调用代码,命令行和测试中强制执行完整性。没有这个,就无法(AFAICT)编写测试来确保模型与特定选择的(非默认)其他模型具有FK关系。

class Payer(models.Model):

    name = models.CharField(blank=True, max_length=100)
    # Nullable, but will enforce FK in clean/save:
    payer_group = models.ForeignKey(PayerGroup, null=True, blank=True,)

    def clean(self):
        # Ensure every Payer is in a PayerGroup (but only via forms)
        if not self.payer_group:
            raise ValidationError(
                {'payer_group': 'Each Payer must belong to a PayerGroup.'})

    def save(self, *args, **kwargs):
        self.full_clean()
        return super().save(*args, **kwargs)

    def __str__(self):
        return self.name

If you have a model that you want to ensure has at least one FK relationship, and you don’t want to use null=False because that requires setting a default FK (which would be garbage data), the best way I’ve come up with is to add custom .clean() and .save() methods. .clean() raises the validation error, and .save() calls the clean. This way the integrity is enforced both from forms and from other calling code, the command line, and tests. Without this, there is (AFAICT) no way to write a test that ensures that a model has a FK relation to a specifically chosen (not default) other model.

class Payer(models.Model):

    name = models.CharField(blank=True, max_length=100)
    # Nullable, but will enforce FK in clean/save:
    payer_group = models.ForeignKey(PayerGroup, null=True, blank=True,)

    def clean(self):
        # Ensure every Payer is in a PayerGroup (but only via forms)
        if not self.payer_group:
            raise ValidationError(
                {'payer_group': 'Each Payer must belong to a PayerGroup.'})

    def save(self, *args, **kwargs):
        self.full_clean()
        return super().save(*args, **kwargs)

    def __str__(self):
        return self.name

回答 5

评论@Alfred Huang的回答和评论。可以通过在当前模块(models.py)中定义一个类列表并在pre_save钩子中对其进行检查来将pre_save钩子锁定到应用程序:

CUSTOM_CLASSES = [obj for name, obj in
        inspect.getmembers(sys.modules[__name__])
        if inspect.isclass(obj)]

@receiver(pre_save)
def pre_save_handler(sender, instance, **kwargs):
    if type(instance) in CUSTOM_CLASSES:
        instance.full_clean()

Commenting on @Alfred Huang’s answer and coments on it. One might lock the pre_save hook down to an app by defining a list of classes in the current module (models.py) and checking against it in the pre_save hook:

CUSTOM_CLASSES = [obj for name, obj in
        inspect.getmembers(sys.modules[__name__])
        if inspect.isclass(obj)]

@receiver(pre_save)
def pre_save_handler(sender, instance, **kwargs):
    if type(instance) in CUSTOM_CLASSES:
        instance.full_clean()

Django管理员中同一模型的多个ModelAdmins /视图

问题:Django管理员中同一模型的多个ModelAdmins /视图

如何为同一个模型创建一个以上的ModelAdmin,每个ModelAdmin进行不同的自定义并链接到不同的URL?

假设我有一个称为Posts的Django模型。默认情况下,此模型的admin视图将列出所有Post对象。

我知道我可以通过设置变量(例如list_display)或queryset在ModelAdmin中重写方法来以各种方式自定义页面上显示的对象列表:

class MyPostAdmin(admin.ModelAdmin):
    list_display = ('title', 'pub_date')

    def queryset(self, request):
        request_user = request.user
        return Post.objects.filter(author=request_user)

admin.site.register(MyPostAdmin, Post)

默认情况下,可以通过URL访问/admin/myapp/post。但是我想拥有同一模型的多个视图/ ModelAdmins。例如,/admin/myapp/post将列出所有帖子对象,并/admin/myapp/myposts列出属于该用户的/admin/myapp/draftpost所有帖子,并可能列出尚未发布的所有帖子。(这些只是示例,我的实际用例更加复杂)

您不能为同一模型注册多个ModelAdmin(这将导致AlreadyRegistered异常)。理想情况下,我希望将所有内容放入单个ModelAdmin类中并编写自己的“ urls”函数以根据URL返回不同的查询集来实现这一点。

我看了看Django的源代码,发现ModelAdmin.changelist_view在urls.py中可以包含这样的函数,但是我不确定它是如何工作的。

更新:我找到了一种实现自己想要的方式(见下文),但是我仍然想听听其他实现方式。

How can I create more than one ModelAdmin for the same model, each customised differently and linked to different URLs?

Let’s say I have a Django model called Posts. By default, the admin view of this model will list all Post objects.

I know I can customise the list of objects displayed on the page in various ways by setting variables like list_display or overriding the queryset method in my ModelAdmin like so:

class MyPostAdmin(admin.ModelAdmin):
    list_display = ('title', 'pub_date')

    def queryset(self, request):
        request_user = request.user
        return Post.objects.filter(author=request_user)

admin.site.register(MyPostAdmin, Post)

By default, this would be accessible at the URL /admin/myapp/post. However I would like to have multiple views/ModelAdmins of the same model. e.g /admin/myapp/post would list all post objects, and /admin/myapp/myposts would list all posts belonging to the user, and /admin/myapp/draftpost might list all posts that have not yet been published. (these are just examples, my actual use-case is more complex)

You cannot register more than one ModelAdmin for the same model (this results in an AlreadyRegistered exception). Ideally I’d like to achieve this without putting everything into a single ModelAdmin class and writing my own ‘urls’ function to return a different queryset depending on the URL.

I’ve had a look at the Django source and I see functions like ModelAdmin.changelist_view that could be somehow included in my urls.py, but I’m not sure exactly how that would work.

Update: I’ve found one way of doing what I want (see below), but I’d still like to hear other ways of doing this.


回答 0

通过使用代理模型来解决每个模型只能注册一次的事实,我找到了一种实现我想要的方法。

class PostAdmin(admin.ModelAdmin):
    list_display = ('title', 'pubdate','user')

class MyPost(Post):
    class Meta:
        proxy = True

class MyPostAdmin(PostAdmin):
    def get_queryset(self, request):
        return self.model.objects.filter(user = request.user)


admin.site.register(Post, PostAdmin)
admin.site.register(MyPost, MyPostAdmin)

然后,默认设置PostAdmin将在处访问,/admin/myapp/post而用户拥有的帖子列表将在/admin/myapp/myposts

看完http://code.djangoproject.com/wiki/DynamicModels之后,我想出了以下函数实用程序函数来做同样的事情:

def create_modeladmin(modeladmin, model, name = None):
    class  Meta:
        proxy = True
        app_label = model._meta.app_label

    attrs = {'__module__': '', 'Meta': Meta}

    newmodel = type(name, (model,), attrs)

    admin.site.register(newmodel, modeladmin)
    return modeladmin

可以如下使用:

class MyPostAdmin(PostAdmin):
    def get_queryset(self, request):
        return self.model.objects.filter(user = request.user)

create_modeladmin(MyPostAdmin, name='my-posts', model=Post)

I’ve found one way to achieve what I want, by using proxy models to get around the fact that each model may be registered only once.

class PostAdmin(admin.ModelAdmin):
    list_display = ('title', 'pubdate','user')

class MyPost(Post):
    class Meta:
        proxy = True

class MyPostAdmin(PostAdmin):
    def get_queryset(self, request):
        return self.model.objects.filter(user = request.user)


admin.site.register(Post, PostAdmin)
admin.site.register(MyPost, MyPostAdmin)

Then the default PostAdmin would be accessible at /admin/myapp/post and the list of posts owned by the user would be at /admin/myapp/myposts.

After looking at http://code.djangoproject.com/wiki/DynamicModels, I’ve come up with the following function utility function to do the same thing:

def create_modeladmin(modeladmin, model, name = None):
    class  Meta:
        proxy = True
        app_label = model._meta.app_label

    attrs = {'__module__': '', 'Meta': Meta}

    newmodel = type(name, (model,), attrs)

    admin.site.register(newmodel, modeladmin)
    return modeladmin

This can be used as follows:

class MyPostAdmin(PostAdmin):
    def get_queryset(self, request):
        return self.model.objects.filter(user = request.user)

create_modeladmin(MyPostAdmin, name='my-posts', model=Post)

回答 1

保罗·斯通的回答绝对是伟大的!补充一下,对于Django 1.4.5,我需要继承自定义类admin.ModelAdmin

class MyPostAdmin(admin.ModelAdmin):
    def queryset(self, request):
        return self.model.objects.filter(id=1)

Paul Stone answer is absolutely great! Just to add, for Django 1.4.5 I needed to inherit my custom class from admin.ModelAdmin

class MyPostAdmin(admin.ModelAdmin):
    def queryset(self, request):
        return self.model.objects.filter(id=1)

Django内容类型到底如何工作?

问题:Django内容类型到底如何工作?

我真的很难理解Django内容类型的概念。感觉非常骇人听闻,并且最终与Python趋向于做事相反。话虽如此,如果我要使用Django,则必须在框架范围内进行工作。

所以我来这里想知道是否有人可以给出有关内容类型如何工作以及如何实现的实际例子。我评论过的几乎所有教程(大部分在博客上)都无法真正涵盖这个概念。他们似乎从Django文档遗忘的地方接手(似乎无处可去)。

I’m really having a difficult time grasping the concept of Django’s content types. It feels very hackish and, ultimately, against how Python tends to do things. That being said, if I’m going to use Django then I have to work within the confines of the framework.

So I’m coming here wondering if anyone can give a practical real world example of how a content type works and how you would implement it. Almost all the tutorials (mostly on blogs) I have reviewed don’t do a great job really covering the concept. They seem to pick up where the Django documentation left off (what seems like nowhere).


回答 0

因此,您想在工作中使用内容类型框架吗?

首先问自己一个问题:“这些模型中的任何一个是否需要与其他模型以相同的方式关联,并且/或者在以后的工作中,我是否会以无法预料的方式重用这些关系?” 我们问这个问题的原因是因为这是Content Types框架最擅长的:它在模型之间创建通用关系。等等,让我们深入研究一些代码,看看我的意思。

# ourapp.models
from django.conf import settings
from django.db import models

# Assign the User model in case it has been "swapped"
User = settings.AUTH_USER_MODEL

# Create your models here
class Post(models.Model):
  author = models.ForeignKey(User)
  title = models.CharField(max_length=75)
  slug = models.SlugField(unique=True)
  body = models.TextField(blank=True)

class Picture(models.Model):
  author = models.ForeignKey(User)
  image = models.ImageField()
  caption = models.TextField(blank=True)

class Comment(models.Model):
  author = models.ForeignKey(User)
  body = models.TextField(blank=True)
  post = models.ForeignKey(Post)
  picture = models.ForeignKey(Picture)

好的,所以我们确实有一种理论上可以建立这种关系的方法。但是,作为Python程序员,您的卓越才智告诉您这很糟糕,您可以做得更好。举手击掌!

进入内容类型框架!

好了,现在我们将仔细研究我们的模型,并对其进行重新设计以使其更加“可重用”和直观。让我们从摆脱Comment模型上的两个外键开始,并用替换它们GenericForeignKey

# ourapp.models
from django.contrib.contenttypes.fields import GenericForeignKey
from django.contrib.contenttypes.models import ContentType

...

class Comment(models.Model):
  author = models.ForeignKey(User)
  body = models.TextField(blank=True)
  content_type = models.ForeignKey(ContentType)
  object_id = models.PositiveIntegerField()
  content_object = GenericForeignKey()

所以发生了什么事?好吧,我们加入并添加了必要的代码,以允许与其他模型建立通用关系。请注意,除了以外GenericForeignKey,还有一个 ForeignKeyto ContentType和a PositiveIntegerField的问题object_id。这些字段用于告诉Django与之相关的对象类型以及该对象的ID。实际上,这是有道理的,因为Django需要同时查找这些相关对象。

好吧,这不是非常像Python的…有点丑陋!

您可能正在寻找能使Guido van Rossum感到骄傲的气密,一尘不染,直观的代码。知道了 让我们看一下这个GenericRelation领域,这样我们就可以为此鞠躬。

# ourapp.models
from django.contrib.contenttypes.fields import GenericRelation

...

class Post(models.Model):
  author = models.ForeignKey(User)
  title = models.CharField(max_length=75)
  slug = models.SlugField(unique=True)
  body = models.TextField(blank=True)
  comments = GenericRelation('Comment')

class Picture(models.Model):
  author = models.ForeignKey(User)
  image = models.ImageField()
  caption = models.TextField(blank=True)
  comments = GenericRelation('Comment')

am!就像这样,您可以为这两个模型使用注释。实际上,让我们继续在shell中进行操作(python manage.py shell从Django项目目录中键入)。

>>> from django.contrib.auth import get_user_model
>>> from ourapp.models import Picture, Post

# We use get_user_model() since we are referencing directly
User = get_user_model()

# Grab our own User object
>>> me = User.objects.get(username='myusername')

# Grab the first of our own pictures so we can comment on it
>>> pic = Picture.objects.get(author=me)

# Let's start making a comment for our own picture
>>> pic.comments.create(author=me, body="Man, I'm cool!")

# Let's go ahead and retrieve the comments for this picture now
>>> pic.comments.all()
[<Comment: "Man, I'm cool!">]

# Same for Post comments
>>> post = Post.objects.get(author=me)
>>> post.comments.create(author=me, body="So easy to comment now!")
>>> post.comments.all()
[<Comment: "So easy to comment now!"]

就这么简单。

这些“一般”关系的其他实际含义是什么?

通用外键可以减少各种应用程序之间的干扰。例如,假设我们将Comment模型拉到了自己的名为的应用中chatterly。现在,我们要创建另一个名为“ noise_nimbus人们存储音乐以与他人共享”的应用程序。

如果我们想在这些歌曲中添加评论怎么办?好吧,我们可以得出一个通用关系:

# noise_nimbus.models
from django.conf import settings
from django.contrib.contenttypes.fields import GenericRelation
from django.db import models

from chatterly.models import Comment

# For a third time, we take the time to ensure custom Auth isn't overlooked
User = settings.AUTH_USER_MODEL

# Create your models here
class Song(models.Model):
  '''
  A song which can be commented on.
  '''
  file = models.FileField()
  author = models.ForeignKey(User)
  title = models.CharField(max_length=75)
  slug = models.SlugField(unique=True)
  description = models.TextField(blank=True)
  comments = GenericRelation(Comment)

我希望你们发现这对您有所帮助,因为我很想遇到一些向我展示了GenericForeignKeyand GenericRelation领域更实际应用的东西。

这好得令人难以置信吗?

与生活中的任何事物一样,也有利弊。每当您添加更多代码和更多抽象时,底层进程就会变得更重且更慢。尽管添加通用关系可能会尝试并智能缓存其结果,但可能会增加一点性能衰减器。总而言之,这取决于清洁度和简单性是否超过了较小的性能成本。对我来说,答案是一百万次。

内容类型框架比我在这里显示的要多。有一个整体的粒度级别和更详细的用法,但是对于一般个人而言,我认为这就是您将使用十分之九的方式。

通用关联器(?)当心!

一个相当大的警告是,当您使用时GenericRelation,如果删除了已GenericRelation应用(Picture)的模型,则所有相关(Comment)对象也将被删除。或至少在撰写本文时。

So you want to use the Content Types framework on your work?

Start by asking yourself this question: “Do any of these models need to be related in the same way to other models and/or will I be reusing these relationships in unforseen ways later down the road?” The reason why we ask this question is because this is what the Content Types framework does best: it creates generic relations between models. Blah blah, let’s dive into some code and see what I mean.

# ourapp.models
from django.conf import settings
from django.db import models

# Assign the User model in case it has been "swapped"
User = settings.AUTH_USER_MODEL

# Create your models here
class Post(models.Model):
  author = models.ForeignKey(User)
  title = models.CharField(max_length=75)
  slug = models.SlugField(unique=True)
  body = models.TextField(blank=True)

class Picture(models.Model):
  author = models.ForeignKey(User)
  image = models.ImageField()
  caption = models.TextField(blank=True)

class Comment(models.Model):
  author = models.ForeignKey(User)
  body = models.TextField(blank=True)
  post = models.ForeignKey(Post)
  picture = models.ForeignKey(Picture)

Okay, so we do have a way to theoretically create this relationship. However, as a Python programmer, your superior intellect is telling you this sucks and you can do better. High five!

Enter the Content Types framework!

Well, now we’re going to take a close look at our models and rework them to be more “reusable” and intuitive. Let’s start by getting rid of the two foreign keys on our Comment model and replace them with a GenericForeignKey.

# ourapp.models
from django.contrib.contenttypes.fields import GenericForeignKey
from django.contrib.contenttypes.models import ContentType

...

class Comment(models.Model):
  author = models.ForeignKey(User)
  body = models.TextField(blank=True)
  content_type = models.ForeignKey(ContentType)
  object_id = models.PositiveIntegerField()
  content_object = GenericForeignKey()

So, what happened? Well, we went in and added the necessary code to allow for a generic relation to other models. Notice how there is more than just a GenericForeignKey, but also a ForeignKey to ContentType and a PositiveIntegerField for the object_id. These fields are for telling Django what type of object this is related to and what the id is for that object. In reality, this makes sense because Django will need both to lookup these related objects.

Well, that’s not very Python-like… its kinda ugly!

You are probably looking for air-tight, spotless, intuitive code that would make Guido van Rossum proud. I get you. Let’s look at the GenericRelation field so we can put a pretty bow on this.

# ourapp.models
from django.contrib.contenttypes.fields import GenericRelation

...

class Post(models.Model):
  author = models.ForeignKey(User)
  title = models.CharField(max_length=75)
  slug = models.SlugField(unique=True)
  body = models.TextField(blank=True)
  comments = GenericRelation('Comment')

class Picture(models.Model):
  author = models.ForeignKey(User)
  image = models.ImageField()
  caption = models.TextField(blank=True)
  comments = GenericRelation('Comment')

Bam! Just like that you can work with the Comments for these two models. In fact, let’s go ahead and do that in our shell (type python manage.py shell from your Django project directory).

>>> from django.contrib.auth import get_user_model
>>> from ourapp.models import Picture, Post

# We use get_user_model() since we are referencing directly
User = get_user_model()

# Grab our own User object
>>> me = User.objects.get(username='myusername')

# Grab the first of our own pictures so we can comment on it
>>> pic = Picture.objects.get(author=me)

# Let's start making a comment for our own picture
>>> pic.comments.create(author=me, body="Man, I'm cool!")

# Let's go ahead and retrieve the comments for this picture now
>>> pic.comments.all()
[<Comment: "Man, I'm cool!">]

# Same for Post comments
>>> post = Post.objects.get(author=me)
>>> post.comments.create(author=me, body="So easy to comment now!")
>>> post.comments.all()
[<Comment: "So easy to comment now!"]

It’s that simple.

What are the other practical implications of these “generic” relations?

Generic foreign keys allow for less intrusive relations between various applications. For example, let’s say we pulled the Comment model out into it’s own app named chatterly. Now we want to create another application named noise_nimbus where people store their music to share with others.

What if we want to add comments to those songs? Well, we can just draw a generic relation:

# noise_nimbus.models
from django.conf import settings
from django.contrib.contenttypes.fields import GenericRelation
from django.db import models

from chatterly.models import Comment

# For a third time, we take the time to ensure custom Auth isn't overlooked
User = settings.AUTH_USER_MODEL

# Create your models here
class Song(models.Model):
  '''
  A song which can be commented on.
  '''
  file = models.FileField()
  author = models.ForeignKey(User)
  title = models.CharField(max_length=75)
  slug = models.SlugField(unique=True)
  description = models.TextField(blank=True)
  comments = GenericRelation(Comment)

I hope you guys found this helpful as I would have loved to have come across something that showed me the more realistic application of GenericForeignKey and GenericRelation fields.

Is this too good to be true?

As with anything in life, there are pros and cons. Anytime you add more code and more abstraction, the underlying processes becomes heavier and a bit slower. Adding generic relations can add a little bit of a performance dampener despite the fact it will try and smart cache its results. All in all, it comes down to whether the cleanliness and simplicity outweighs the small performance costs. For me, the answer is a million times yes.

There is more to the Content Types framework than I have displayed here. There is a whole level of granularity and more verbose usage, but for the average individual, this is how you will be using it 9 out of 10 times in my opinion.

Generic relationizers(?) beware!

A rather large caveat is that when you use a GenericRelation, if the model which has the GenericRelation applied (Picture) is deleted, all related (Comment) objects will also be deleted. Or at least as of the time of this writing.


回答 1

好的,您的问题的直接答案是:(来自django源代码)是: 根据RFC 2616,第3.7节分析媒体类型。

这是流泪的说法,它读取/允许您修改/传递“ Content-type” httpd标头。

但是,您需要一个更多的实践用法示例。我为您提供2条建议:

1:检查此代码

def index(request):
   media_type='text/html'
   if request.META.has_key('CONTENT_TYPE'):
      media_type = request.META['CONTENT_TYPE'].split(';')[0]

   if media_type.lower() == 'application/json':
      return HttpResponse("""{ "ResponseCode": "Success"}""", content_type="application/json; charset=UTF-8")

   return HttpResponse("<h1>regular old joe</h1>");

2:请记住django是python,因此它具有python社区的功能。django有2个很棒的RESTFul插件。因此,如果您想了解兔子整体的深度,可以查看一下。

我建议阅读django-rest-framework教程,该教程将专门解决“作用于不同内容/类型”的问题。注意:通常的做法是使用content-type标头对RESTful API进行“版本化”

Ok well the direct answer to your question: ( from the django source code ) is: Media Types parsing according to RFC 2616, section 3.7.

Which is the tears way of saying that it reads/allows-you-to-modify/passes along the ‘Content-type’ httpd header.

However, you are asking for a more practice usage example. I have 2 suggestions for you:

1: examine this code

def index(request):
   media_type='text/html'
   if request.META.has_key('CONTENT_TYPE'):
      media_type = request.META['CONTENT_TYPE'].split(';')[0]

   if media_type.lower() == 'application/json':
      return HttpResponse("""{ "ResponseCode": "Success"}""", content_type="application/json; charset=UTF-8")

   return HttpResponse("<h1>regular old joe</h1>");

2: remember django is python, and as such it wields the power of the python community. There are 2 awesome RESTFul plugins to django. So if you want to see how deep the rabbit whole goes you can check out.

I suggest going through the django-rest-framework tutorial which will address ‘acting on different content/types’ specifically. Note: It is common practice to use the content-type header to ‘version’ restful API’s.


Django Admin-禁用特定模型的“添加”操作

问题:Django Admin-禁用特定模型的“添加”操作

我有一个包含很多模型和表格的django网站。我有许多自定义表单和表单集以及inlineformsets和自定义验证和自定义查询集。因此,添加模型操作取决于需要其他内容的表单,并且Django管理员中的“添加模型”通过自定义查询集中的500进行操作。

无论如何,对于某些型号,是否禁用“添加$ MODEL”功能?

我想/admin/appname/modelname/add/给出一个404(或适当的“ goaway”错误消息),我不希望显示“ Add $ MODELNAME”按钮/admin/appname/modelname

Django管理员提供了一种禁用管理员操作的方法(http://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/#disabling-actions),但是此模型的唯一操作是“ delete_selected”。即,管理员操作仅作用于现有模型。有一些Django风格的方法来做到这一点吗?

I have a django site with lots of models and forms. I have many custom forms and formsets and inlineformsets and custom validation and custom querysets. Hence the add model action depends on forms that need other things, and the ‘add model’ in the django admin throughs a 500 from a custom queryset.

Is there anyway to disable the ‘Add $MODEL’ functionality for a certain models?

I want /admin/appname/modelname/add/ to give a 404 (or suitable ‘go away’ error message), I don’t want the ‘Add $MODELNAME’ button to be on /admin/appname/modelname view.

Django admin provides a way to disable admin actions (http://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/#disabling-actions) however the only action for this model is ‘delete_selected’. i.e. the admin actions only act on existing models. Is there some django-esque way to do this?


回答 0

这很简单,只需has_add_permission在您的Admin类中重载方法,如下所示:

class MyAdmin(admin.ModelAdmin):
     def has_add_permission(self, request, obj=None):
        return False

It is easy, just overload has_add_permission method in your Admin class like so:

class MyAdmin(admin.ModelAdmin):
     def has_add_permission(self, request, obj=None):
        return False

回答 1

默认情况下,syncdb为每个模型创建3个安全权限:

  1. 创建(又名添加)
  2. 更改
  3. 删除

如果您以Admin身份登录,则无论如何,您将获得一切

但是,如果您创建一个名为“常规访问”的新用户组(例如),则只能为所有模型分配“更改”和“删除”权限。

然后,任何属于该组成员的登录用户将没有“创建”权限,与此相关的任何内容都不会显示在屏幕上。

By default syncdb creates 3 security permissions for each model:

  1. Create (aka add)
  2. Change
  3. Delete

If your logged in as Admin, you get EVERYTHING no matter what.

But if you create a new user group called “General Access” (for example) then you can assign ONLY the CHANGE and DELETE permissions for all of your models.

Then any logged in user that is a member of that group will not have “Create” permission, nothing related to it will show on the screen.


回答 2

我认为这将对您有所帮助..下面的代码必须在admin.py文件中

@admin.register(Author)
class AuthorAdmin(admin.ModelAdmin):
    list_display = ('name', )
    list_filter = ('name', )
    search_fields = ('name', )
    list_per_page = 20

    # This will help you to disbale add functionality
    def has_add_permission(self, request):
        return False

    # This will help you to disable delete functionaliyt
    def has_delete_permission(self, request, obj=None):
        return False

除上述内容外,发布者

    # This will help you to disable change functionality
    def has_change_permission(self, request, obj=None):
        return False

I think this will help you.. below code must be in admin.py file

@admin.register(Author)
class AuthorAdmin(admin.ModelAdmin):
    list_display = ('name', )
    list_filter = ('name', )
    search_fields = ('name', )
    list_per_page = 20

    # This will help you to disbale add functionality
    def has_add_permission(self, request):
        return False

    # This will help you to disable delete functionaliyt
    def has_delete_permission(self, request, obj=None):
        return False

In additon to the above as posted by

    # This will help you to disable change functionality
    def has_change_permission(self, request, obj=None):
        return False

回答 3

只需复制另一个答案中的代码

# In admin
# make the related field can't be added
    def get_form(self, request, obj=None, **kwargs):
        form = super().get_form(request, obj, **kwargs)
        form.base_fields['service'].widget.can_add_related = False
        return form

就我而言,我使用内联

# In inline formset e.g. admin.TabularInline
# disable all
    def get_formset(self, request, obj=None, **kwargs):
        formset = super().get_formset(request, obj, **kwargs)
        service = formset.form.base_fields['service']
        service.widget.can_add_related = service.widget.can_change_related = service.widget.can_delete_related = False
        return formset

service = formset.form.base_fields['service'] base_fields是模型中定义的字段

如果以以下形式定义:

product = formset.form.declared_fields['product']

也可以看看

Just copy code from another answer

# In admin
# make the related field can't be added
    def get_form(self, request, obj=None, **kwargs):
        form = super().get_form(request, obj, **kwargs)
        form.base_fields['service'].widget.can_add_related = False
        return form

In my case I use inline

# In inline formset e.g. admin.TabularInline
# disable all
    def get_formset(self, request, obj=None, **kwargs):
        formset = super().get_formset(request, obj, **kwargs)
        service = formset.form.base_fields['service']
        service.widget.can_add_related = service.widget.can_change_related = service.widget.can_delete_related = False
        return formset

in service = formset.form.base_fields['service'] base_fields is the fields defined in model

if defined in the form use:

product = formset.form.declared_fields['product']

see also


回答 4

这是一个过于延迟的答案;只需将其发布,就好像有人在寻找相同的解决方案一样。

在admin.py文件中,您可以执行以下操作:

class MyModelForm(forms.ModelForm):

class Meta:
    model = MyModel
    fields = '__all__'


class MyModelAdmin(admin.ModelAdmin):
    form = QuestionTrackAdminForm
    list_display = ['title', 'weight']
    readonly_fields = ['title', 'weight']

admin.site.register(MyModel, MyModelAdmin)

在这里,“ readonly_fields”起到了神奇的作用。谢谢。

This is a too much delayed answer; Just posting this as if anyone is finding the same solution.

In admin.py file you can do the following:

class MyModelForm(forms.ModelForm):

class Meta:
    model = MyModel
    fields = '__all__'


class MyModelAdmin(admin.ModelAdmin):
    form = QuestionTrackAdminForm
    list_display = ['title', 'weight']
    readonly_fields = ['title', 'weight']

admin.site.register(MyModel, MyModelAdmin)

Here, “readonly_fields” does the magic. Thanks.


在Django中,如何检查用户是否在某个组中?

问题:在Django中,如何检查用户是否在某个组中?

我在Django的管理站点中创建了一个自定义组。

在我的代码中,我想检查用户是否在该组中。我怎么做?

I created a custom group in Django’s admin site.

In my code, I want to check if a user is in this group. How do I do that?


回答 0

您只需通过上的groups属性即可访问组User

from django.contrib.auth.models import User, Group

group = Group(name = "Editor")
group.save()                    # save this new group for this example
user = User.objects.get(pk = 1) # assuming, there is one initial user 
user.groups.add(group)          # user is now in the "Editor" group

然后user.groups.all()返回[<Group: Editor>]

另外,更直接地,您可以通过以下方式检查用户是否在群组中:

if django_user.groups.filter(name = groupname).exists():

    ...

注意,groupname可以是实际的Django组对象。

You can access the groups simply through the groups attribute on User.

from django.contrib.auth.models import User, Group

group = Group(name = "Editor")
group.save()                    # save this new group for this example
user = User.objects.get(pk = 1) # assuming, there is one initial user 
user.groups.add(group)          # user is now in the "Editor" group

then user.groups.all() returns [<Group: Editor>].

Alternatively, and more directly, you can check if a a user is in a group by:

if django_user.groups.filter(name = groupname).exists():

    ...

Note that groupname can also be the actual Django Group object.


回答 1

您的User对象通过ManyToMany关系链接到Group对象。

因此,您可以将filter方法应用于user.groups

因此,要检查给定的用户是否在某个组中(例如“成员”),只需执行以下操作:

def is_member(user):
    return user.groups.filter(name='Member').exists()

如果要检查给定用户是否属于多个给定组,请使用__in运算符,如下所示:

def is_in_multiple_groups(user):
    return user.groups.filter(name__in=['group1', 'group2']).exists()

请注意,这些功能可以与@user_passes_test装饰器一起使用,以管理对视图的访问:

from django.contrib.auth.decorators import login_required, user_passes_test
@login_required
@user_passes_test(is_member) # or @user_passes_test(is_in_multiple_groups)
def myview(request):
    # Do your processing

希望有帮助

Your User object is linked to the Group object through a ManyToMany relationship.

You can thereby apply the filter method to user.groups.

So, to check if a given User is in a certain group (“Member” for the example), just do this :

def is_member(user):
    return user.groups.filter(name='Member').exists()

If you want to check if a given user belongs to more than one given groups, use the __in operator like so :

def is_in_multiple_groups(user):
    return user.groups.filter(name__in=['group1', 'group2']).exists()

Note that those functions can be used with the @user_passes_test decorator to manage access to your views :

from django.contrib.auth.decorators import login_required, user_passes_test
@login_required
@user_passes_test(is_member) # or @user_passes_test(is_in_multiple_groups)
def myview(request):
    # Do your processing

Hope this help


回答 2

如果需要组中的用户列表,则可以改为:

from django.contrib.auth.models import Group
users_in_group = Group.objects.get(name="group name").user_set.all()

然后检查

 if user in users_in_group:
     # do something

检查用户是否在组中。

If you need the list of users that are in a group, you can do this instead:

from django.contrib.auth.models import Group
users_in_group = Group.objects.get(name="group name").user_set.all()

and then check

 if user in users_in_group:
     # do something

to check if the user is in the group.


回答 3

如果您不需要网站上的用户实例(就像我一样),可以使用

User.objects.filter(pk=userId, groups__name='Editor').exists()

这只会对数据库产生一个请求,并返回一个布尔值。

If you don’t need the user instance on site (as I did), you can do it with

User.objects.filter(pk=userId, groups__name='Editor').exists()

This will produce only one request to the database and return a boolean.


回答 4

如果用户属于某个组,则可以使用以下方法在Django模板中进行检查:

{% if group in request.user.groups.all %} "some action" {% endif %}

If a user belongs to a certain group or not, can be checked in django templates using:

{% if group in request.user.groups.all %} "some action" {% endif %}


回答 5

您只需要一行:

from django.contrib.auth.decorators import user_passes_test  

@user_passes_test(lambda u: u.groups.filter(name='companyGroup').exists())
def you_view():
    return HttpResponse("Since you're logged in, you can see this text!")

You just need one line:

from django.contrib.auth.decorators import user_passes_test  

@user_passes_test(lambda u: u.groups.filter(name='companyGroup').exists())
def you_view():
    return HttpResponse("Since you're logged in, you can see this text!")

回答 6

万一您想检查用户的组是否属于预定义的组列表,以防万一:

def is_allowed(user):
    allowed_group = set(['admin', 'lead', 'manager'])
    usr = User.objects.get(username=user)
    groups = [ x.name for x in usr.groups.all()]
    if allowed_group.intersection(set(groups)):
       return True
    return False

Just in case if you wanna check user’s group belongs to a predefined group list:

def is_allowed(user):
    allowed_group = set(['admin', 'lead', 'manager'])
    usr = User.objects.get(username=user)
    groups = [ x.name for x in usr.groups.all()]
    if allowed_group.intersection(set(groups)):
       return True
    return False

回答 7

我有类似的情况,我想测试用户是否在某个组中。因此,我创建了新文件utils.py,在其中放置了所有有助于整个应用程序的小型实用程序。在那里,我有这个定义:

utils.py

def is_company_admin(user):
    return user.groups.filter(name='company_admin').exists()

所以基本上我正在测试用户是否在company_admin组中,为了清楚起见,我将此函数称为is_company_admin

当我要检查用户是否在company_admin中时,只需执行以下操作:

views.py

from .utils import *

if is_company_admin(request.user):
        data = Company.objects.all().filter(id=request.user.company.id)

现在,如果您希望在模板中进行测试,则可以在上下文中添加is_user_admin,如下所示:

views.py

return render(request, 'admin/users.html', {'data': data, 'is_company_admin': is_company_admin(request.user)})

现在,您可以在模板中评估您的响应:

users.html

{% if is_company_admin %}
     ... do something ...
{% endif %}

简单而干净的解决方案,基于可以在该线程的较早版本中找到的答案,但是以不同的方式进行。希望它会帮助某人。

在Django 3.0.4中测试。

I have similar situation, I wanted to test if the user is in a certain group. So, I’ve created new file utils.py where I put all my small utilities that help me through entire application. There, I’ve have this definition:

utils.py

def is_company_admin(user):
    return user.groups.filter(name='company_admin').exists()

so basically I am testing if the user is in the group company_admin and for clarity I’ve called this function is_company_admin.

When I want to check if the user is in the company_admin I just do this:

views.py

from .utils import *

if is_company_admin(request.user):
        data = Company.objects.all().filter(id=request.user.company.id)

Now, if you wish to test same in your template, you can add is_user_admin in your context, something like this:

views.py

return render(request, 'admin/users.html', {'data': data, 'is_company_admin': is_company_admin(request.user)})

Now you can evaluate you response in a template:

users.html

{% if is_company_admin %}
     ... do something ...
{% endif %}

Simple and clean solution, based on answers that can be found earlier in this thread, but done differently. Hope it will help someone.

Tested in Django 3.0.4.


回答 8

一行:

'Groupname' in user.groups.values_list('name', flat=True)

这等于TrueFalse

In one line:

'Groupname' in user.groups.values_list('name', flat=True)

This evaluates to either True or False.


回答 9

我已经按照以下方式完成了。似乎效率低下,但我心中没有其他选择:

@login_required
def list_track(request):

usergroup = request.user.groups.values_list('name', flat=True).first()
if usergroup in 'appAdmin':
    tracks = QuestionTrack.objects.order_by('pk')
    return render(request, 'cmit/appadmin/list_track.html', {'tracks': tracks})

else:
    return HttpResponseRedirect('/cmit/loggedin')

I have done it the following way. Seems inefficient but I had no other way in my mind:

@login_required
def list_track(request):

usergroup = request.user.groups.values_list('name', flat=True).first()
if usergroup in 'appAdmin':
    tracks = QuestionTrack.objects.order_by('pk')
    return render(request, 'cmit/appadmin/list_track.html', {'tracks': tracks})

else:
    return HttpResponseRedirect('/cmit/loggedin')

回答 10

User.objects.filter(username='tom', groups__name='admin').exists()

该查询将通知您用户:“ tom”是否属于“ admin”组

User.objects.filter(username='tom', groups__name='admin').exists()

That query will inform you user : “tom” whether belong to group “admin ” or not


回答 11

我是这样做的。对于名为的组Editor

# views.py
def index(request):
    current_user_groups = request.user.groups.values_list("name", flat=True)
    context = {
        "is_editor": "Editor" in current_user_groups,
    }
    return render(request, "index.html", context)

模板

# index.html
{% if is_editor %}
  <h1>Editor tools</h1>
{% endif %}

I did it like this. For group named Editor.

# views.py
def index(request):
    current_user_groups = request.user.groups.values_list("name", flat=True)
    context = {
        "is_editor": "Editor" in current_user_groups,
    }
    return render(request, "index.html", context)

template

# index.html
{% if is_editor %}
  <h1>Editor tools</h1>
{% endif %}

在Django模型中存储列表的最有效方法是什么?

问题:在Django模型中存储列表的最有效方法是什么?

目前,我的代码中有很多类似于以下内容的python对象:

class MyClass():
  def __init__(self, name, friends):
      self.myName = name
      self.myFriends = [str(x) for x in friends]

现在,我想将其转换为Django模型,其中self.myName是字符串字段,而self.myFriends是字符串列表。

from django.db import models

class myDjangoModelClass():
    myName = models.CharField(max_length=64)
    myFriends = ??? # what goes here?

由于列表是python中如此常见的数据结构,因此我希望它有一个Django模型字段。我知道我可以使用ManyToMany或OneToMany关系,但是我希望避免代码中的额外间接访问。

编辑:

我添加了这个相关问题,人们可能会发现它很有用。

Currently I have a lot of python objects in my code similar to the following:

class MyClass():
  def __init__(self, name, friends):
      self.myName = name
      self.myFriends = [str(x) for x in friends]

Now I want to turn this into a Django model, where self.myName is a string field, and self.myFriends is a list of strings.

from django.db import models

class myDjangoModelClass():
    myName = models.CharField(max_length=64)
    myFriends = ??? # what goes here?

Since the list is such a common data structure in python, I sort of expected there to be a Django model field for it. I know I can use a ManyToMany or OneToMany relationship, but I was hoping to avoid that extra indirection in the code.

Edit:

I added this related question, which people may find useful.


回答 0

将这种关系更好地表示为Friends表的一对多外键关系吗?我知道这myFriends只是字符串,但我认为更好的设计是创建一个Friend模型,并MyClass在结果表中包含外键。

Would this relationship not be better expressed as a one-to-many foreign key relationship to a Friends table? I understand that myFriends are just strings but I would think that a better design would be to create a Friend model and have MyClass contain a foreign key realtionship to the resulting table.


回答 1

“过早的优化是万恶之源。”

牢记这一点,让我们开始吧!一旦您的应用达到特定点,对数据进行非规范化就非常普遍。正确完成后,它可以节省大量昂贵的数据库查找,但需要多做一些整理工作。

要返回一个list朋友名称,我们需要创建一个自定义Django Field类,该类在访问时将返回一个列表。

David Cramer在他的博客上发布了有关创建SeperatedValueField的指南。这是代码:

from django.db import models

class SeparatedValuesField(models.TextField):
    __metaclass__ = models.SubfieldBase

    def __init__(self, *args, **kwargs):
        self.token = kwargs.pop('token', ',')
        super(SeparatedValuesField, self).__init__(*args, **kwargs)

    def to_python(self, value):
        if not value: return
        if isinstance(value, list):
            return value
        return value.split(self.token)

    def get_db_prep_value(self, value):
        if not value: return
        assert(isinstance(value, list) or isinstance(value, tuple))
        return self.token.join([unicode(s) for s in value])

    def value_to_string(self, obj):
        value = self._get_val_from_obj(obj)
        return self.get_db_prep_value(value)

此代码的逻辑处理从数据库到Python的序列化和反序列化值,反之亦然。现在,您可以轻松地导入并使用模型类中的自定义字段:

from django.db import models
from custom.fields import SeparatedValuesField 

class Person(models.Model):
    name = models.CharField(max_length=64)
    friends = SeparatedValuesField()

“Premature optimization is the root of all evil.”

With that firmly in mind, let’s do this! Once your apps hit a certain point, denormalizing data is very common. Done correctly, it can save numerous expensive database lookups at the cost of a little more housekeeping.

To return a list of friend names we’ll need to create a custom Django Field class that will return a list when accessed.

David Cramer posted a guide to creating a SeperatedValueField on his blog. Here is the code:

from django.db import models

class SeparatedValuesField(models.TextField):
    __metaclass__ = models.SubfieldBase

    def __init__(self, *args, **kwargs):
        self.token = kwargs.pop('token', ',')
        super(SeparatedValuesField, self).__init__(*args, **kwargs)

    def to_python(self, value):
        if not value: return
        if isinstance(value, list):
            return value
        return value.split(self.token)

    def get_db_prep_value(self, value):
        if not value: return
        assert(isinstance(value, list) or isinstance(value, tuple))
        return self.token.join([unicode(s) for s in value])

    def value_to_string(self, obj):
        value = self._get_val_from_obj(obj)
        return self.get_db_prep_value(value)

The logic of this code deals with serializing and deserializing values from the database to Python and vice versa. Now you can easily import and use our custom field in the model class:

from django.db import models
from custom.fields import SeparatedValuesField 

class Person(models.Model):
    name = models.CharField(max_length=64)
    friends = SeparatedValuesField()

回答 2

在Django中存储列表的一种简单方法是将其转换为JSON字符串,然后将其另存为模型中的Text。然后,您可以通过将(JSON)字符串转换回python列表来检索列表。这是如何做:

“列表”将存储在您的Django模型中,如下所示:

class MyModel(models.Model):
    myList = models.TextField(null=True) # JSON-serialized (text) version of your list

在您的视图/控制器代码中:

将列表存储在数据库中:

import simplejson as json # this would be just 'import json' in Python 2.7 and later
...
...

myModel = MyModel()
listIWantToStore = [1,2,3,4,5,'hello']
myModel.myList = json.dumps(listIWantToStore)
myModel.save()

从数据库中检索列表:

jsonDec = json.decoder.JSONDecoder()
myPythonList = jsonDec.decode(myModel.myList)

从概念上讲,这是正在发生的事情:

>>> myList = [1,2,3,4,5,'hello']
>>> import simplejson as json
>>> myJsonList = json.dumps(myList)
>>> myJsonList
'[1, 2, 3, 4, 5, "hello"]'
>>> myJsonList.__class__
<type 'str'>
>>> jsonDec = json.decoder.JSONDecoder()
>>> myPythonList = jsonDec.decode(myJsonList)
>>> myPythonList
[1, 2, 3, 4, 5, u'hello']
>>> myPythonList.__class__
<type 'list'>

A simple way to store a list in Django is to just convert it into a JSON string, and then save that as Text in the model. You can then retrieve the list by converting the (JSON) string back into a python list. Here’s how:

The “list” would be stored in your Django model like so:

class MyModel(models.Model):
    myList = models.TextField(null=True) # JSON-serialized (text) version of your list

In your view/controller code:

Storing the list in the database:

import simplejson as json # this would be just 'import json' in Python 2.7 and later
...
...

myModel = MyModel()
listIWantToStore = [1,2,3,4,5,'hello']
myModel.myList = json.dumps(listIWantToStore)
myModel.save()

Retrieving the list from the database:

jsonDec = json.decoder.JSONDecoder()
myPythonList = jsonDec.decode(myModel.myList)

Conceptually, here’s what’s going on:

>>> myList = [1,2,3,4,5,'hello']
>>> import simplejson as json
>>> myJsonList = json.dumps(myList)
>>> myJsonList
'[1, 2, 3, 4, 5, "hello"]'
>>> myJsonList.__class__
<type 'str'>
>>> jsonDec = json.decoder.JSONDecoder()
>>> myPythonList = jsonDec.decode(myJsonList)
>>> myPythonList
[1, 2, 3, 4, 5, u'hello']
>>> myPythonList.__class__
<type 'list'>

回答 3

如果您将Django> = 1.9与Postgres一起使用,可以利用ArrayField的优势

用于存储数据列表的字段。可以使用大多数字段类型,您只需将另一个字段实例作为base_field传递即可。您也可以指定尺寸。可以嵌套ArrayField来存储多维数组。

也可以嵌套数组字段:

from django.contrib.postgres.fields import ArrayField
from django.db import models

class ChessBoard(models.Model):
    board = ArrayField(
        ArrayField(
            models.CharField(max_length=10, blank=True),
            size=8,
        ),
        size=8,
    )

正如@ thane-brimhall所提到的,也可以直接查询元素。文档参考

If you are using Django >= 1.9 with Postgres you can make use of ArrayField advantages

A field for storing lists of data. Most field types can be used, you simply pass another field instance as the base_field. You may also specify a size. ArrayField can be nested to store multi-dimensional arrays.

It is also possible to nest array fields:

from django.contrib.postgres.fields import ArrayField
from django.db import models

class ChessBoard(models.Model):
    board = ArrayField(
        ArrayField(
            models.CharField(max_length=10, blank=True),
            size=8,
        ),
        size=8,
    )

As @thane-brimhall mentioned it is also possible to query elements directly. Documentation reference


回答 4

由于这是一个古老的问题,自此之后Django技术必定发生了重大变化,因此该答案反映了Django 1.4版,并且很可能适用于v 1.5。

Django默认使用关系数据库。您应该利用’em。使用ManyToManyField将友谊映射到数据库关系(外键约束)。这样做使您可以将RelatedManagers用于使用智能查询集的朋友列表。您可以使用所有可用的方法,例如filtervalues_list

使用ManyToManyField关系和属性:

class MyDjangoClass(models.Model):
    name = models.CharField(...)
    friends = models.ManyToManyField("self")

    @property
    def friendlist(self):
        # Watch for large querysets: it loads everything in memory
        return list(self.friends.all())

您可以通过以下方式访问用户的朋友列表:

joseph = MyDjangoClass.objects.get(name="Joseph")
friends_of_joseph = joseph.friendlist

但是请注意,这些关系是对称的:如果约瑟夫是鲍勃的朋友,那么鲍勃是约瑟夫的朋友。

As this is an old question, and Django techniques must have changed significantly since, this answer reflects Django version 1.4, and is most likely applicable for v 1.5.

Django by default uses relational databases; you should make use of ’em. Map friendships to database relations (foreign key constraints) with the use of ManyToManyField. Doing so allows you to use RelatedManagers for friendlists, which use smart querysets. You can use all available methods such as filter or values_list.

Using ManyToManyField relations and properties:

class MyDjangoClass(models.Model):
    name = models.CharField(...)
    friends = models.ManyToManyField("self")

    @property
    def friendlist(self):
        # Watch for large querysets: it loads everything in memory
        return list(self.friends.all())

You can access a user’s friend list this way:

joseph = MyDjangoClass.objects.get(name="Joseph")
friends_of_joseph = joseph.friendlist

Note however that these relations are symmetrical: if Joseph is a friend of Bob, then Bob is a friend of Joseph.


回答 5

class Course(models.Model):
   name = models.CharField(max_length=256)
   students = models.ManyToManyField(Student)

class Student(models.Model):
   first_name = models.CharField(max_length=256)
   student_number = models.CharField(max_length=128)
   # other fields, etc...

   friends = models.ManyToManyField('self')
class Course(models.Model):
   name = models.CharField(max_length=256)
   students = models.ManyToManyField(Student)

class Student(models.Model):
   first_name = models.CharField(max_length=256)
   student_number = models.CharField(max_length=128)
   # other fields, etc...

   friends = models.ManyToManyField('self')

回答 6

请记住,这最终必须在关系数据库中结束。因此,使用关系确实解决此问题的常用方法。如果绝对要在对象本身中存储列表,则可以使用逗号分隔列表,然后将其存储在字符串中,然后提供将字符串拆分为列表的访问器函数。这样,您将被限制为最大数量的字符串,并且您将失去有效的查询。

Remember that this eventually has to end up in a relational database. So using relations really is the common way to solve this problem. If you absolutely insist on storing a list in the object itself, you could make it for example comma-separated, and store it in a string, and then provide accessor functions that split the string into a list. With that, you will be limited to a maximum number of strings, and you will lose efficient queries.


回答 7

如果您使用的是postgres,则可以使用以下代码:

class ChessBoard(models.Model):

    board = ArrayField(
        ArrayField(
            models.CharField(max_length=10, blank=True),
            size=8,
        ),
        size=8,
    )

如果您需要更多详细信息,请阅读以下链接:https : //docs.djangoproject.com/pt-br/1.9/ref/contrib/postgres/fields/

In case you’re using postgres, you can use something like this:

class ChessBoard(models.Model):

    board = ArrayField(
        ArrayField(
            models.CharField(max_length=10, blank=True),
            size=8,
        ),
        size=8,
    )

if you need more details you can read in the link below: https://docs.djangoproject.com/pt-br/1.9/ref/contrib/postgres/fields/


回答 8

您可以使用Django Pickle Field来存储几乎任何对象,例如以下代码段:

http://www.djangosnippets.org/snippets/513/

You can store virtually any object using a Django Pickle Field, ala this snippet:

http://www.djangosnippets.org/snippets/513/


回答 9

在Django模型中存储字符串列表:

class Bar(models.Model):
    foo = models.TextField(blank=True)

    def set_list(self, element):
        if self.foo:
            self.foo = self.foo + "," + element
        else:
            self.foo = element

    def get_list(self):
        if self.foo:
            return self.foo.split(",")
        else:
            None

您可以这样称呼它:

bars = Bar()
bars.set_list("str1")
bars.set_list("str2")
list = bars.get_list()
if list is not None:
    for bar in list:
        print bar
else:
    print "List is empty."      

Storing a list of strings in Django model:

class Bar(models.Model):
    foo = models.TextField(blank=True)

    def set_list(self, element):
        if self.foo:
            self.foo = self.foo + "," + element
        else:
            self.foo = element

    def get_list(self):
        if self.foo:
            return self.foo.split(",")
        else:
            None

and you can call it like this:

bars = Bar()
bars.set_list("str1")
bars.set_list("str2")
list = bars.get_list()
if list is not None:
    for bar in list:
        print bar
else:
    print "List is empty."      

回答 10

我的解决方案可能是它可以帮助某人:

import json
from django.db import models


class ExampleModel(models.Model):
    _list = models.TextField(default='[]')

    @property
    def list(self):
        return json.loads(self._list)

    @list.setter
    def list(self, value):
        self._list = json.dumps(self.list + value)

My solution, may be it helps someone:

import json
from django.db import models


class ExampleModel(models.Model):
    _list = models.TextField(default='[]')

    @property
    def list(self):
        return json.loads(self._list)

    @list.setter
    def list(self, value):
        self._list = json.dumps(self.list + value)

回答 11

使用一对多关系(从Friend到父类的FK)将使您的应用程序更具可伸缩性(因为您可以使用简单名称之外的其他属性来简单地扩展Friend对象)。因此这是最好的方法

Using one-to-many relation (FK from Friend to parent class) will make your app more scalable (as you can trivially extend the Friend object with additional attributes beyond the simple name). And thus this is the best way


在此Django应用程序教程中,choice_set是什么?

问题:在此Django应用程序教程中,choice_set是什么?

Django教程中的这一行,编写您的第一个Django应用,第1部分

p.choice_set.create(choice='Not much', votes=0)

它是如何choice_set存在的?它是什么?

我想这choice部分是Choice本教程中使用的模型的小写版本,但是什么是choice_set?你能详细说明吗?

更新:根据Ben的回答,我找到了此文档:遵循“向后”关系

There is this line in the Django tutorial, Writing your first Django app, part 1:

p.choice_set.create(choice='Not much', votes=0)

How is choice_set called into existence and what is it?

I suppose the choice part is the lowercase version of the model Choice used in the tutorial, but what is choice_set? Can you elaborate?

UPDATE: Based on Ben‘s answer, I located this documentation: Following relationships “backward”.


回答 0

您创建了一个外键Choice,每个外键都与关联Question

因此,每个Choice显式都有一个question字段,您可以在模型中声明该字段。

Django的ORM也遵循这种关系Question,在每个实例上自动生成一个名为foo_setwhere Foo是模型的ForeignKey字段,其中包含该模型的字段。

choice_set是一个RelatedManager可以创建ChoiceQuestion实例相关的对象的查询集的,例如q.choice_set.all()

如果您不喜欢foo_setDjango自动选择的命名,或者您对同一个模型拥有多个外键并需要区分它们,则可以使用related_name参数to 来选择自己的替代名称ForeignKey

You created a foreign key on Choice which relates each one to a Question.

So, each Choice explicitly has a question field, which you declared in the model.

Django’s ORM follows the relationship backwards from Question too, automatically generating a field on each instance called foo_set where Foo is the model with a ForeignKey field to that model.

choice_set is a RelatedManager which can create querysets of Choice objects which relate to the Question instance, e.g. q.choice_set.all()

If you don’t like the foo_set naming which Django chooses automatically, or if you have more than one foreign key to the same model and need to distinguish them, you can choose your own overriding name using the related_name argument to ForeignKey.


使用Django / South重命名模型的最简单方法?

问题:使用Django / South重命名模型的最简单方法?

我一直在South的网站,Google和SO上寻找答案,但是找不到简单的方法来做到这一点。

我想使用South重命名Django模型。说您有以下几点:

class Foo(models.Model):
    name = models.CharField()

class FooTwo(models.Model):
    name = models.CharField()
    foo = models.ForeignKey(Foo)

并且您想要将Foo转换为Bar,即

class Bar(models.Model):
    name = models.CharField()

class FooTwo(models.Model):
    name = models.CharField()
    foo = models.ForeignKey(Bar)

为简单起见,我只是尝试将名称从更改FooBar,但现在忽略其中的foo成员FooTwo

使用South进行此操作最简单的方法是什么?

  1. 我可能可以进行数据迁移,但这似乎很复杂。
  2. 编写一个自定义迁移,例如db.rename_table('city_citystate', 'geo_citystate'),但是在这种情况下我不确定如何修复外键。
  3. 您知道一种更简单的方法吗?

I’ve been hunting for an answer to this on South’s site, Google, and SO, but couldn’t find a simple way to do this.

I want to rename a Django model using South. Say you have the following:

class Foo(models.Model):
    name = models.CharField()

class FooTwo(models.Model):
    name = models.CharField()
    foo = models.ForeignKey(Foo)

and you want to convert Foo to Bar, namely

class Bar(models.Model):
    name = models.CharField()

class FooTwo(models.Model):
    name = models.CharField()
    foo = models.ForeignKey(Bar)

To keep it simple, I’m just trying to change the name from Foo to Bar, but ignore the foo member in FooTwo for now.

What’s the easiest way to do this using South?

  1. I could probably do a data migration, but that seems pretty involved.
  2. Write a custom migration, e.g. db.rename_table('city_citystate', 'geo_citystate'), but I’m not sure how to fix the foreign key in this case.
  3. An easier way that you know?

回答 0

为了回答您的第一个问题,简单的模型/表重命名非常简单。运行命令:

./manage.py schemamigration yourapp rename_foo_to_bar --empty

(更新2:尝试--auto,而不是--empty避免低于警告感谢@KFB的提示。)

如果您使用的是南方的旧版本,则需要startmigration而不是schemamigration

然后手动编辑迁移文件,如下所示:

class Migration(SchemaMigration):

    def forwards(self, orm):
        db.rename_table('yourapp_foo', 'yourapp_bar')


    def backwards(self, orm):
        db.rename_table('yourapp_bar','yourapp_foo')   

您可以使用db_table模型类中的Meta选项来更简单地完成此操作。但是每次这样做,都增加了代码库的旧版权重-类名与表名不同会使代码难以理解和维护。为了清楚起见,我完全支持进行这样的简单重构。

(更新)我刚刚在生产环境中尝试过此操作,并在应用迁移时收到一个奇怪的警告。它说:

The following content types are stale and need to be deleted:

    yourapp | foo

Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.

我回答“不”,一切似乎都很好。

To answer your first question, the simple model/table rename is pretty straightforward. Run the command:

./manage.py schemamigration yourapp rename_foo_to_bar --empty

(Update 2: try --auto instead of --empty to avoid the warning below. Thanks to @KFB for the tip.)

If you’re using an older version of south, you’ll need startmigration instead of schemamigration.

Then manually edit the migration file to look like this:

class Migration(SchemaMigration):

    def forwards(self, orm):
        db.rename_table('yourapp_foo', 'yourapp_bar')


    def backwards(self, orm):
        db.rename_table('yourapp_bar','yourapp_foo')   

You can accomplish this more simply using the db_table Meta option in your model class. But every time you do that, you increase the legacy weight of your codebase — having class names differ from table names makes your code harder to understand and maintain. I fully support doing simple refactorings like this for the sake of clarity.

(update) I just tried this in production, and got a strange warning when I went to apply the migration. It said:

The following content types are stale and need to be deleted:

    yourapp | foo

Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.

I answered “no” and everything seemed to be fine.


回答 1

进行更改models.py,然后运行

./manage.py schemamigration --auto myapp

检查迁移文件时,您会看到它删除了一个表并创建了一个新表。

class Migration(SchemaMigration):

    def forwards(self, orm):
        # Deleting model 'Foo'                                                                                                                      
        db.delete_table('myapp_foo')

        # Adding model 'Bar'                                                                                                                        
        db.create_table('myapp_bar', (
        ...
        ))
        db.send_create_signal('myapp', ['Bar'])

    def backwards(self, orm):
        ...

这不是您想要的。而是编辑迁移,使其看起来像:

class Migration(SchemaMigration):

    def forwards(self, orm):
        # Renaming model from 'Foo' to 'Bar'                                                                                                                      
        db.rename_table('myapp_foo', 'myapp_bar')                                                                                                                        
        if not db.dry_run:
            orm['contenttypes.contenttype'].objects.filter(
                app_label='myapp', model='foo').update(model='bar')

    def backwards(self, orm):
        # Renaming model from 'Bar' to 'Foo'                                                                                                                      
        db.rename_table('myapp_bar', 'myapp_foo')                                                                                                                        
        if not db.dry_run:
            orm['contenttypes.contenttype'].objects.filter(app_label='myapp', model='bar').update(model='foo')

在没有该update语句的情况下,该db.send_create_signal调用将ContentType使用新的模型名称创建一个新的模型。但它最好只updateContentType你已经拥有的情况下有数据库对象指向它(例如,通过一GenericForeignKey)。

另外,如果您已经重命名了某些列,这些列是重命名模型的外键,请不要忘记

db.rename_column(myapp_model, foo_id, bar_id)

Make the changes in models.py and then run

./manage.py schemamigration --auto myapp

When you inspect the migration file, you’ll see that it deletes a table and creates a new one

class Migration(SchemaMigration):

    def forwards(self, orm):
        # Deleting model 'Foo'                                                                                                                      
        db.delete_table('myapp_foo')

        # Adding model 'Bar'                                                                                                                        
        db.create_table('myapp_bar', (
        ...
        ))
        db.send_create_signal('myapp', ['Bar'])

    def backwards(self, orm):
        ...

This is not quite what you want. Instead, edit the migration so that it looks like:

class Migration(SchemaMigration):

    def forwards(self, orm):
        # Renaming model from 'Foo' to 'Bar'                                                                                                                      
        db.rename_table('myapp_foo', 'myapp_bar')                                                                                                                        
        if not db.dry_run:
            orm['contenttypes.contenttype'].objects.filter(
                app_label='myapp', model='foo').update(model='bar')

    def backwards(self, orm):
        # Renaming model from 'Bar' to 'Foo'                                                                                                                      
        db.rename_table('myapp_bar', 'myapp_foo')                                                                                                                        
        if not db.dry_run:
            orm['contenttypes.contenttype'].objects.filter(app_label='myapp', model='bar').update(model='foo')

In the absence of the update statement, the db.send_create_signal call will create a new ContentType with the new model name. But it’s better to just update the ContentType you already have in case there are database objects pointing to it (e.g., via a GenericForeignKey).

Also, if you’ve renamed some columns which are foreign keys to the renamed model, don’t forget to

db.rename_column(myapp_model, foo_id, bar_id)

回答 2

南方本身不能做-怎么知道这Bar代表Foo过去?我将为此编写自定义迁移。您可以ForeignKey像上面所做的那样更改in代码,然后只是重命名适当的字段和表的一种情况,您可以根据需要进行任何操作。

最后,您真的需要这样做吗?我还不需要重命名模型-模型名称只是实现细节-特别是考虑到verbose_nameMeta选项的可用性。

South can’t do it itself – how does it know that Bar represents what Foo used to? This is the sort of thing I’d write a custom migration for. You can change your ForeignKey in code as you’ve done above, and then it’s just a case of renaming the appropriate fields and tables, which you can do any way you want.

Finally, do you really need to do this? I’ve yet to need to rename models – model names are just an implementation detail – particularly given the availability of the verbose_name Meta option.


回答 3

我遵循了上面Leopd的解决方案。但是,这并没有更改型号名称。我在代码中手动更改了它(在相关模型中也将其称为FK)。并进行了另一个南迁,但带有–fake选项。这使得模型名称和表名称相同。

刚意识到,可以先从更改模型名称开始,然后在应用迁移文件之前编辑迁移文件。干净得多。

I followed Leopd’s solution above. But, that did not change the model names. I changed it manually in the code (also in related models where this is referred as FK). And done another south migration, but with –fake option. This makes model names and table names to be same.

Just realized, one could first start with changing model names, then edit the migrations file before applying them. Much cleaner.


我什么时候应该使用ugettext_lazy?

问题:我什么时候应该使用ugettext_lazy?

我有一个关于使用ugettext和ugettext_lazy进行翻译的问题。我了解到,在模型ugettext_lazyugettext中,我应该在中使用。但是还有其他地方我也应该使用ugettext_lazy吗?表单定义呢?它们之间是否存在性能差异?

编辑: 还有一件事。有时候,代替ugettext_lazyugettext_noop被使用。正如文档所述,ugettext_noop仅在将字符串显示给用户之前,才将字符串标记为要翻译,并在可能的最新情况下进行翻译,但是我在这里有点困惑,这与功能相似ugettext_lazy吗?我仍然很难决定在模型和表格中应该使用哪个。

I have a question about using ugettext and ugettext_lazy for translations. I learned that in models I should use ugettext_lazy, while in views ugettext. But are there any other places, where I should use ugettext_lazy too? What about form definitions? Are there any performance diffrences between them?

Edit: And one more thing. Sometimes, instead of ugettext_lazy, ugettext_noop is used. As documentation says, ugettext_noop strings are only marked for translation and translated at the latest possible momment before displaying them to the user, but I’m little confused here, isn’t that similar to what ugettext_lazy do? It’s still hard for me to decide, which should I use in my models and forms.


回答 0

ugettext()ugettext_lazy()

在诸如表单或模型之类的定义中,您应该使用ugettext_lazy此定义,因为此定义的代码仅执行一次(通常在django启动时);ugettext_lazy以懒惰的方式翻译字符串,例如 每次访问模型上的属性名称时,字符串都会被重新翻译-这完全有意义,因为自django启动以来,您可能正在使用不同的语言查看该模型!

在视图和类似的函数调用中,您可以ugettext毫无问题地使用它,因为每次调用该视图时ugettext都会重新执行该视图,因此您将始终获得适合请求的正确翻译!

关于 ugettext_noop()

正如布莱斯在他的答案中指出的那样,此函数将字符串标记为可提取以进行翻译,但会返回未翻译的字符串。这对于在两个地方使用该字符串很有用-已翻译和未翻译。请参见以下示例:

import logging
from django.http import HttpResponse
from django.utils.translation import ugettext as _, ugettext_noop as _noop

def view(request):
    msg = _noop("An error has occurred")
    logging.error(msg)
    return HttpResponse(_(msg))

ugettext() vs. ugettext_lazy()

In definitions like forms or models you should use ugettext_lazy because the code of this definitions is only executed once (mostly on django’s startup); ugettext_lazy translates the strings in a lazy fashion, which means, eg. every time you access the name of an attribute on a model the string will be newly translated-which totally makes sense because you might be looking at this model in different languages since django was started!

In views and similar function calls you can use ugettext without problems, because everytime the view is called ugettext will be newly executed, so you will always get the right translation fitting the request!

Regarding ugettext_noop()

As Bryce pointed out in his answer, this function marks a string as extractable for translation but does return the untranslated string. This is useful for using the string in two places – translated and untranslated. See the following example:

import logging
from django.http import HttpResponse
from django.utils.translation import ugettext as _, ugettext_noop as _noop

def view(request):
    msg = _noop("An error has occurred")
    logging.error(msg)
    return HttpResponse(_(msg))

回答 1

_noop的一个很好的用法是,当您想以英语记录开发人员的消息,但将翻译后的字符串显示给查看者时。例如:http://blog.bessas.me/posts/using-gettext-in-django/

An excellent use of _noop, is when you want to log a message in English for the developers, but present the translated string to a viewer. An example of this is at http://blog.bessas.me/posts/using-gettext-in-django/


回答 2

惰性版本返回代理对象而不是字符串,并且在某些情况下无法正常工作。例如:

def get(self, request, format=None):
   search_str = request.GET.get('search', '')
   data = self.search(search_str)
   lst = []
   lst.append({'name': ugettext_lazy('Client'), 'result': data})
   return HttpResponse(json.dumps(lst), content_type='application/json')

会失败,因为最后一行将尝试将lst对象序列化为JSON,而不是“ client”的字符串,它将具有一个代理对象。代理对象无法序列化为json。

The lazy version returns a proxy object instead of a string and in some situation it would not work as expected. For example:

def get(self, request, format=None):
   search_str = request.GET.get('search', '')
   data = self.search(search_str)
   lst = []
   lst.append({'name': ugettext_lazy('Client'), 'result': data})
   return HttpResponse(json.dumps(lst), content_type='application/json')

would fail because very last line would try serialize lst object into JSON and instead of a string for “client” it would have a proxy object. The proxy object is not serializeable into json.