Onde os manipuladores de sinal devem viver em um projeto de django?

Acabei de começar a implementar ouvintes de sinal em um projeto de django. Enquanto eu entendo o que são e como usá-los. Estou tendo dificuldade para descobrir onde devo colocá-los. A documentação do site django tem o seguinte a dizer:

Onde esse código deve estar?

Você pode colocar código de manuseio e registro de sinal onde quiser. No entanto, você precisará garantir que o módulo em que ele está seja importado desde o início, para que o tratamento do sinal seja registrado antes que qualquer sinal precise ser enviado. Isso torna o models.py do seu aplicativo um bom local para registrar os manipuladores de sinal.

Embora seja uma boa sugestão, ter classes ou métodos não modelados em meus models.py apenas me atrapalha.

Então, qual é a melhor prática / regra para armazenar e registrar manipuladores de sinal?

Na verdade, gosto de torná-los métodos de classe do próprio modelo. Isso mantém tudo dentro de uma classe e significa que você não precisa se preocupar em importar nada.

Isso foi adicionado à documentação quando o Django 1.7 foi lançado:

Estritamente falando, o código de manipulação e registro de sinal pode viver em qualquer lugar que você quiser, embora seja recomendável evitar o módulo raiz do aplicativo e o módulo de modelos para minimizar os efeitos colaterais da importação de código.

Na prática, os manipuladores de sinais são geralmente definidos em um submódulo de sinais do aplicativo ao qual se relacionam. Os receptores de sinal são conectados no método ready () da sua classe de configuração do aplicativo. Se você estiver usando o decorador receiver (), basta importar o submódulo de sinais para ready ().

Alterado no Django 1.7: Como o ready () não existia nas versões anteriores do Django, o registro do sinal geralmente acontecia no módulo de modelos.

A melhor prática é definir seus manipuladores em handlers.py em um submódulo de sinais, por exemplo, um arquivo parecido com:

yourapp / signs / handlers.py :

from django.db.models.signals import pre_save
from django.dispatch import receiver
from myapp.models import MyModel

@receiver(pre_save, sender=MyModel)
def my_handler(sender, **kwargs):
    pass

O melhor lugar para registrar seu manipulador de sinal é o AppConfig do aplicativo que o define, usando o método ready () . Isso ficará assim:

yourapp / apps.py :

from django.apps import AppConfig

class TasksConfig(AppConfig):
    name = 'tasks'
    verbose_name = "Tasks"

    def ready(self):
        import yourproject.yourapp.signals.handlers #noqa

Verifique se você está carregando o AppConfig, especificando-o diretamente em INSTALLED_APPS do settings.py ou no __init__aplicativo. Veja a documentação ready () para mais informações.

Nota: Se você estiver fornecendo sinais para outros aplicativos também ouvirem, coloque-os __init__no módulo de sinais, por exemplo, um arquivo parecido com:

yourapp / signs / __ init__.py

import django.dispatch

task_generate_pre_save = django.dispatch.Signal(providing_args=["task"])

Outro aplicativo pode ouvir seu sinal importando e registrando-o, por exemplo from yourapp.signals import task_generate_pre_save. Separar os sinais dos manipuladores mantém as coisas limpas.

Instruções para o Django 1.6:

Se você ainda está preso no Django 1.6 ou inferior, faça o mesmo (defina seus manipuladores em yourapp / signs / handlers.py), mas em vez de usar o AppConfig, carregue os manipuladores através do __init__.py de seu aplicativo, por exemplo, algo como:

yourapp / __ init__.py

import signals

Isso não é tão bom quanto usar o método ready () porque geralmente causa problemas de importação circular.

Acabei de descobrir isso e, como meus sinais não são relacionados ao modelo, pensei em adicionar minha solução.

Estou registrando vários dados em torno de login / logout e necessário conectar django.contrib.auth.signals.

Coloquei os manipuladores de sinal em um signals.pyarquivo e depois importei os sinais do __init__.pyarquivo do módulo, pois acredito que isso é chamado assim que o aplicativo é iniciado (o teste com uma printinstrução sugere que ele seja chamado antes mesmo de o arquivo de configurações ser lido).

# /project/__init__.py
import signals

e em signs.py

# /project/signals.py
from django.contrib.auth.signals import user_logged_in

def on_logged_in(sender, user, request, **kwargs):
    print 'User logged in as: \'{0}\''.format(user)

user_logged_in.connect(on_logged_in)

Eu sou bem novo no Django (/ python), então estou aberto a qualquer um que me diga que essa é uma péssima idéia!

Recentemente, li este artigo sobre as práticas recomendadas no que diz respeito ao layout de seus projetos / aplicativos e sugere que todos os seus sinais personalizados do despachante devem ir em um arquivo chamado signals.py. No entanto, isso não resolve completamente o seu problema, pois você ainda precisa importá-los para algum lugar, e quanto mais cedo eles forem importados, melhor.

A sugestão do modelo é boa. Como você já definiu tudo no seu signals.pyarquivo, não deve demorar mais do que uma linha na parte superior do arquivo. É semelhante à maneira como o admin.pyarquivo é organizado (com definições de classe na parte superior e o código para registrar todas as classes administrativas personalizadas na parte inferior), se você definir seus sinais, conecte-os no mesmo arquivo.

Espero que ajude! Em última análise, tudo se resume ao que você prefere.

models.py e signs.py em cada aplicativo foram os locais recomendados para conectar sinais; no entanto, eles não são a melhor solução, na minha opinião, para manter os sinais e manipuladores enviados. O envio deve ser a razão pela qual os sinais e manipuladores inventados no django.

Eu estava lutando por um longo tempo e finalmente descobrimos a solução.

crie um módulo de conector na pasta do aplicativo

então nós temos:

app/
    __init__.py
    signals.py
    models.py
    connectors.py

em app / connectors.py, definimos manipuladores de sinais e os conectamos. Um exemplo é fornecido:

from signals import example_signal
from models import ExampleModel
from django.db.models.signals import post_save, post_delete

def hanndler(sender, *args, **kwargs):
    pass

post_save.connect(hander, sender=ExampleModel)

depois, em models.py, adicionamos a seguinte linha no final do arquivo:

from app import connector

Tudo feito aqui.

Dessa forma, podemos colocar sinais em signs.py e todos os manipuladores em connectors.py. Sem bagunça nos modelos e sinais.

Espero que ele forneça outra solução.

Eu os mantenho em um arquivo separado signals.py, models.pydepois que todos os modelos estiverem definidos. Eu os importo e conecto modelos a sinais.

signs.py

#  necessary imports

def send_mail_on_save(<args>):
    # code here 

models.py

# imports
class mymodel(models.Model):
    # model here

# import signals
from signals import send_mail_on_save
# connect them 
post_save.connect(send_mail_on_save,sender=mymodel)

Isso me fornece uma separação lógica, é claro que não há nada errado em mantê-los em models.py , mas é mais gerenciável dessa maneira.

Espero que isto ajude!!

Pequeno lembrete sobre AppConfig. Não se esqueça de definir:

# yourapp/__init__.py

default_app_config = 'yourapp.apps.RockNRollConfig'