Monday, October 29, 2012

Re: signals documentation question

Russell

I haven't gotten around to using signals just yet so it will be a while
before I can suck it and see. I was just reading up because they look
like a solution to a particular design problem I have. I've gone back to
the specs for the moment.

Thanks for the fast response.

Cheers

Mike

On 30/10/2012 4:55pm, Russell Keith-Magee wrote:
>
> On Tue, Oct 30, 2012 at 1:40 PM, Mike Dewhirst <miked@dewhirst.com.au
> <mailto:miked@dewhirst.com.au>> wrote:
>
> The 1.5 docs say ...
>
> Where should this code live?
> 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.
>
> ... and my question:
>
> When models live in a models directory instead of models.py, should
> the signal handling and registration code go in __init__.py where
> the models are imported?
>
>
> There isn't really going to be a *good* answer for this, due to the
> general problems that exist with having reliable, one-time-import-only
> startup routine. __init__.py is probably as good a place as any (modulo
> the usual arguments against putting code in __init__.py); the actual
> files providing the models would be another candidate location.
>
> However, this will all depend on the exact import patterns that exist in
> your own code. Even putting signals in a 'normal' models.py file can be
> problematic, depending on how you import your code. Essentially -- suck
> it and see; if you start seeing multiple signals being fired
> unexpectedly, investigate the ways your code is being imported, and
> either simplify those imports, or find another location to put the
> registrations.
>
> As an aside -- this is one of the reasons we need help landing the #3591
> app-refactor branch. One of the side effects of this branch will be a
> reliable startup mechanism for apps, which will provide somewhere you
> can put code (like signal registrations) that needs to be invoked
> exactly once at the startup of the stack.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

No comments:

Post a Comment