blocks|key|307149|text|我最近刚刚读了一篇关于项目/应用程序布局的最佳实践的this文章，文章建议所有自定义调度程序信号都应该放在一个名为signals.py的文件中。然而，这并不能完全解决你的问题，因为你仍然需要把它们导入到某个地方，而且越早导入越好。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|307150|模型建议是一个很好的建议。因为您已经在signals.py文件中定义了所有内容，所以在文件的顶部不应该超过一行。这类似于admin.py文件的布局方式(类定义在顶部，用于注册所有自定义管理类的代码在底部)，如果您定义了信号，则将它们连接到同一文件中。|307151|希望这能有所帮助！归根结底，这取决于你的喜好。|307152|entityMap|0|LINK|mutability|MUTABLE|url|http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/^0|1L|A|Q|4|0|0|J|A|1O|8|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|12|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

I just recently read <a href="http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/" rel="noreferrer">this</a> article about best practices when it comes to lay out your projects/applications, and it suggests that all your custom dispatcher signals should go in a file called <code>signals.py</code>. However, that doesn't fully solve your problem, since you still need to import these somewhere, and the earlier they get imported the better.

The model suggestion is a good one. Since you already defined everything in your <code>signals.py</code> file, it shouldn't take more than a line at the top of the the file. This is similar to the way the <code>admin.py</code> file is laid out (with class definitions at the top and the code for registering all the custom admin classes at the bottom), if you define your signals then connect them in the same file.

Hope that helps! Ultimately it comes down to what you prefer.

blocks|key|3261072|text|实际上，我喜欢让它们成为模型本身的类方法。这使所有内容都保持在一个类中，这意味着您不必担心导入任何内容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3261073|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I actually like to make them classmethods of the model itself. That keeps everything within one class, and means you don't have to worry about importing anything.

blocks|key|3261101|text|我刚刚接触到这一点，因为我的信号与模型无关，所以我想我应该添加我的解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3261102|我正在登录/注销周围的各种数据，并需要挂钩到django.contrib.auth.signals。|offset|length|style|CODE|3261103|我将信号处理程序放到一个signals.py文件中，然后从__init__.py模块文件导入信号，因为我相信这会在应用程序启动时立即调用(使用print语句进行的测试表明，甚至在读取设置文件之前就会调用它)。|3261104|#+/project/__init__.py
import+signals|code-block|syntax|javascript|3261105|在signals.py中|3261106|#+/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)|3261107|我是Django+(/python)的新手，所以我愿意接受任何人告诉我这是一个糟糕的想法！|3261108|entityMap^0|0|M|R|0|C|A|T|B|1Z|5|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@$D|Y|E|Z|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|10|8|@$D|11|E|12|F|G]|$D|13|E|14|F|G]|$D|15|E|16|F|G]]|9|@]|A|$]]|$1|J|3|K|5|L|7|17|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|19|8|@]|9|@]|A|$M|N]]|$1|S|3|T|5|6|7|1A|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|V|$]]

I've only just come across this, and as my signals are not model-related I thought I'd add my solution. 

I am logging various data around log in / log out, and needed to hook into <code>django.contrib.auth.signals</code>. 

I have put the signal handlers into a <code>signals.py</code> file, and then imported signals from the <code>__init__.py</code> module file, as I believe this is called as soon as the app starts up (testing with a <code>print</code> statement suggests that it's called even before the settings file is read.) 

<pre><code># /project/__init__.py
import signals
</code></pre>

and in signals.py

<pre><code># /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)
</code></pre>

I'm pretty new to Django (/python) so am open to anyone telling me that this is a terrible idea!

blocks|key|307176|text|每个应用程序中的models.py和signals.py都是连接信号的推荐位置，然而，在我看来，它们不是保持信号和处理程序调度的最佳解决方案。调度应该是django发明信号和处理程序的原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|307177|我挣扎了很长一段时间，最后我们找到了解决方案。|307178|在应用文件夹中创建连接器模块|offset|length|style|BOLD|307179|所以我们有：|307180|app/
++++__init__.py
++++signals.py
++++models.py
++++connectors.py|code-block|syntax|javascript|307181|在app/connectors.py中，我们定义了信号处理程序并将它们连接起来。下面提供了一个示例：|307182|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)|307183|然后在models.py中，我们在文件的末尾添加以下行：|307184|from+app+import+connector|307185|这里的一切都做好了。|307186|通过这种方式，我们可以将信号放在signals.py中，并将所有处理程序放在connectors.py中。没有混乱的模型和信号。|307187|希望它能提供另一种解决方案。|307188|entityMap^0|0|0|0|6|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|18|8|@$F|19|G|1A|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1B|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1C|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|1D|8|@]|9|@]|A|$]]|$1|S|3|T|5|N|7|1E|8|@]|9|@]|A|$O|P]]|$1|U|3|V|5|6|7|1F|8|@]|9|@]|A|$]]|$1|W|3|X|5|N|7|1G|8|@]|9|@]|A|$O|P]]|$1|Y|3|Z|5|6|7|1H|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1I|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1J|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|15|$]]

models.py and signals.py in each app have been the recommended places to connect signals, however, they are not the best solution, in my opinion, to keep signals and handlers dispatched. Dispatching should be the reason signals and handlers invented in django. 

I was struggling for long time, and finally we figured out the solution.

create a connector module in app folder

so we have: 

<pre><code>app/
 __init__.py
 signals.py
 models.py
 connectors.py
</code></pre>

in app/connectors.py, we defined signal handlers and connect them. An example is provided: 

<pre><code>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)
</code></pre>

then in models.py, we add the following line in the end of the file:

<pre><code>from app import connector
</code></pre>

Everything done here. 

In this way, we can put signals in signals.py, and all the handlers in connectors.py. No mess in models and signals. 

Hope it provides another solution.

blocks|key|307233|text|这是在Django+1.7发布时添加到documentation中的：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|307234|307235|严格地说，信号处理和注册代码可以放在您喜欢的任何地方，尽管建议避免应用程序的根模块及其模型模块，以最大限度地减少导入代码的副作用。|blockquote|307236|307237|在实践中，信号处理程序通常在与其相关的应用程序的信号子模块中定义。信号接收器连接在应用程序配置类的ready()方法中。如果您使用receiver()修饰器，只需在ready()中导入信号子模块。|307238|Django+1.7中的更改:由于ready()在以前的Django版本中不存在，因此信号注册通常发生在模型模块中。|307239|307240|最佳实践是在handlers.py中的信号子模块中定义处理程序，例如，如下所示的文件：|307241|yourapp/signals/handlers.py|307242|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|code-block|syntax|javascript|307243|注册信号处理程序的最佳位置是在定义它的应用程序的AppConfig中，使用ready()方法。这看起来像这样：|307244|yourapp/apps.py|307245|from+django.apps+import+AppConfig

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

++++def+ready(self):
++++++++import+yourproject.yourapp.signals.handlers+#noqa|307246|确保通过直接在settings.py的INSTALLED_APPS中或在应用程序的__init__中指定AppConfig来加载它。有关详细信息，请参阅see+the+ready()+documentation。|CODE|307247|注意:如果您也为其他应用程序提供了监听信号，请将它们放入您的信号模块的__init__中，例如，一个如下所示的文件：|307248|yourapp/signals/__init__.py|307249|import+django.dispatch

task_generate_pre_save+=+django.dispatch.Signal(providing_args=["task"])|307250|然后，另一个应用程序可以通过导入和注册来监听您的信号，例如from+yourapp.signals+import+task_generate_pre_save。将你的信号从你的处理程序中分离出来，可以保持事情的整洁。|307251|Django1.6的说明：|307252|如果你仍然停留在Django1.6或更低版本，那么你会做同样的事情(在你的same+/signals/Handlers.py中定义你的处理程序)，但不是使用AppConfig，你会通过你的应用程序的__init__.py加载处理程序，例如：|307253|您可以使用/__init__.py|307254|import+signals|307255|这不如使用ready()方法好，因为它经常导致循环导入问题。|307256|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.djangoproject.com/en/1.8/topics/signals/|1|https://docs.djangoproject.com/en/dev/ref/applications/#django.apps.AppConfig.ready^0|3|A|J|D|0|0|0|0|0|0|0|0|0|0|0|11|7|0|0|0|15|8|24|T|1|0|Z|8|0|0|0|T|1E|0|A|3|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1Z|8|@$9|20|A|21|B|C]]|D|@$9|22|A|23|1|24]]|E|$]]|$1|F|3|-4|5|6|7|25|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|26|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|27|8|@]|D|@]|E|$]]|$1|K|3|L|5|6|7|28|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|29|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|2A|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|2B|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|2C|8|@]|D|@]|E|$]]|$1|T|3|U|5|V|7|2D|8|@]|D|@]|E|$W|X]]|$1|Y|3|Z|5|6|7|2E|8|@$9|2F|A|2G|B|C]]|D|@]|E|$]]|$1|10|3|11|5|6|7|2H|8|@]|D|@]|E|$]]|$1|12|3|13|5|V|7|2I|8|@]|D|@]|E|$W|X]]|$1|14|3|15|5|6|7|2J|8|@$9|2K|A|2L|B|16]]|D|@$9|2M|A|2N|1|2O]]|E|$]]|$1|17|3|18|5|6|7|2P|8|@$9|2Q|A|2R|B|16]]|D|@]|E|$]]|$1|19|3|1A|5|6|7|2S|8|@]|D|@]|E|$]]|$1|1B|3|1C|5|V|7|2T|8|@]|D|@]|E|$W|X]]|$1|1D|3|1E|5|6|7|2U|8|@$9|2V|A|2W|B|16]]|D|@]|E|$]]|$1|1F|3|1G|5|6|7|2X|8|@$9|2Y|A|2Z|B|C]]|D|@]|E|$]]|$1|1H|3|1I|5|6|7|30|8|@]|D|@]|E|$]]|$1|1J|3|1K|5|6|7|31|8|@]|D|@]|E|$]]|$1|1L|3|1M|5|V|7|32|8|@]|D|@]|E|$W|X]]|$1|1N|3|1O|5|6|7|33|8|@]|D|@]|E|$]]|$1|1P|3|-4|5|6|7|34|8|@]|D|@]|E|$]]]|1Q|$1R|$5|1S|1T|1U|E|$1V|1W]]|1X|$5|1S|1T|1U|E|$1V|1Y]]]]

This was added to the <a href="https://docs.djangoproject.com/en/1.8/topics/signals/" rel="noreferrer">documentation</a> when Django 1.7 was released:

<blockquote>
 Strictly speaking, signal handling and registration code can live anywhere you like, although it’s recommended to avoid the application’s root module and its models module to minimize side-effects of importing code.
 
 In practice, signal handlers are usually defined in a signals submodule of the application they relate to. Signal receivers are connected in the ready() method of your application configuration class. If you’re using the receiver() decorator, simply import the signals submodule inside ready().
 
 Changed in Django 1.7: Since ready() didn’t exist in previous versions of Django, signal registration usually happened in the models module.
</blockquote>

Best practice is to define your handlers in handlers.py in a signals submodule, e.g. a file that looks like:

yourapp/signals/handlers.py:

<pre><code>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
</code></pre>

The best place to register your signal handler is then in the AppConfig of the app that defines it, using the ready() method. This will look like this:

yourapp/apps.py:

<pre><code>from django.apps import AppConfig

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

 def ready(self):
 import yourproject.yourapp.signals.handlers #noqa
</code></pre>

Make sure you're loading your AppConfig by specifying it either directly in your settings.py's INSTALLED_APPS, or in the <code>__init__</code> of your app. See <a href="https://docs.djangoproject.com/en/dev/ref/applications/#django.apps.AppConfig.ready" rel="noreferrer">see the ready() documentation</a> for more information.

Note: If you're providing signals for other apps to listen too as well, put them in the <code>__init__</code> in your signals module, e.g. a file that looks like:

yourapp/signals/__init__.py

<pre><code>import django.dispatch

task_generate_pre_save = django.dispatch.Signal(providing_args=["task"])
</code></pre>

Another app can then listen to your signal by importing and registering it, e.g. <code>from yourapp.signals import task_generate_pre_save</code>. Separating your signals from your handlers keeps things clean.

Instructions for Django 1.6:

If you're still stuck on Django 1.6 or lower, then you'd do the same thing (define your handlers in yourapp/signals/handlers.py) but rather than using AppConfig, you would load the handlers via the __init__.py of your app, e.g. something like:

yourapp/__init__.py

<pre><code>import signals
</code></pre>

This isn't as nice as using the ready() method because it often causes circular import issues.

blocks|key|3047596|text|在定义完所有模型之后，我将它们保存在models.py中的一个单独的文件signals.py中。我导入它们并将模型连接到信号。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3047597|signals.py|3047598|#++necessary+imports

def+send_mail_on_save(<args>):
++++#+code+here+|code-block|syntax|javascript|3047599|models.py|3047600|#+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)|3047601|这为我提供了逻辑分离，当然，将它们保留在models.py中没有什么问题，但这种方式更易于管理。|BOLD|3047602|希望这能有所帮助！！|3047603|entityMap^0|I|9|10|A|0|0|0|0|0|K|9|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|12|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|13|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|14|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|15|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|16|8|@$9|17|A|18|B|S]]|D|@]|E|$]]|$1|T|3|U|5|6|7|19|8|@]|D|@]|E|$]]|$1|V|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|W|$]]

I keep them in a separate file <code>signals.py</code> , In <code>models.py</code> after all models are defined. I import them and connect models to signals.

signals.py

<pre><code># necessary imports

def send_mail_on_save(&lt;args&gt;):
 # code here 
</code></pre>

models.py

<pre><code># 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)
</code></pre>

This provides me logical separation, of course there is nothing wrong on keeping them in models.py , But it is more manageable this way.

Hope this helps!!

blocks|key|310285|text|关于AppConfig的小提醒。别忘了设置：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|310286|#+yourapp/__init__.py

default_app_config+=+'yourapp.apps.RockNRollConfig'|code-block|syntax|javascript|310287|entityMap^0|2|9|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|P|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|L|$]]

Small reminder about <code>AppConfig</code>. Don't forget to set:

<pre class="lang-py prettyprint-override"><code># yourapp/__init__.py

default_app_config = 'yourapp.apps.RockNRollConfig'
</code></pre>

I have just started implementing signal listeners in a django project. While I understand what they are and how to use them. I am having a hard time figuring out where I should put them. The documentation from the django site has this to say:

<blockquote>
 <a href="http://docs.djangoproject.com/en/dev/topics/signals/#connecting-receiver-functions" rel="noreferrer">Where should this code live?</a>
 
 You can put signal handling and
 registration code anywhere you like.
 However, you'll need to make sure that
 the module it's in gets imported early
 on so that the signal handling gets
 registered before any signals need to
 be sent. This makes your app's
 models.py a good place to put
 registration of signal handlers.
</blockquote>

While its a good suggestion, having non model classes or methods in my models.py just rubs me the wrong way.

So then, what is the best practice/rule for storing and registering signal handlers?

Where should signal handlers live in a django project?

Django

我刚刚开始在django项目中实现信号侦听器。当我了解它们是什么以及如何使用它们时。我很难弄清楚我应该把它们放在哪里。django站点上的文档是这样说的： 你可以把信号处理和注册码放在你喜欢的任何地方。但是，您需要确保在早期导入它所在的模块，以便在需要发送任何信号之前注册信号处理。这使得你的应用程序的models.py...

问在django项目中，信号处理程序应该放在哪里？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在django项目中，信号处理程序应该放在哪里？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在django项目中，信号处理程序应该放在哪里？
EN