On Aug 18, 6:31 pm, Mathieu Leduc-Hamel <marra...@gmail.com> wrote: > Richard, > > it's not the good way to do this, in the settings.py cause as i said before, > the code in the settings.py is executed every time somebody initiate a > session for the first time. The point there is a way to have a part of code > common to all currently connected user.
It may be the way you are explaining it is bad, but 'settings.py' is not executed every time somebody initiates a session for the first time. At least as far as what I think you could mean by session. Ideally 'settings.py' will only be loaded once in the life of a process hosting a Django instance. Sad fact is that that isn't the case, and depending on how you host Django, it can be loaded twice. Once as 'settings' and once as 'mysite.settings'. For an explanation of why that is the case read: http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html Either way, it is bad practice to put code in settings.py file other than straight variable assignments. It is definitely not a good idea to put code in there which performs actions which are cumulative because of chance for multiple loading. For example, something that loads a lot of stuff into a cache for example would be better elsewhere. This is because it would be wasted effort, but depending on the type of action, could also result in duplicated data being added to something. If you are hosting under Apache/mod_wsgi, Phusion Passenger or uWSGI where they use a distinct WSGI script file, you can usually put actions to be performed once in that file. There is a trap in this though, in that default WSGI script file recipes don't cause proper preloading of Django code and settings configuration. Your actions may trigger that too occur, but better off using different WSGI script file recipe as explained in blog post referenced above. At the end of that script file, then add the actions you need to run. Some argue though that that is causing stuff to run that doesn't necessarily need to run in a production setting. The next catch is that for Apache/mod_wsgi, not sure about others, it will only load that WSGI script file when the first request arrives that requires it. This lazy loading means that that first request will see any start up cost from those actions being run. Under Apache/ mod_wsgi at least, if you therefore what the actions to be run when process starts, rather than when first request arrives, you should look at the WSGIImportScript directive to force load the WSGI script on process start. Now, this will only work for hosting mechanisms that use a distinct WSGI script file. It will not work for Django development server. This is where I believe twod.wsgi comes in that it tries to do things in a way with Django startup that works on any system. FWIW, I believe the lack of consistency in web deployment, even when WSGI interface is used, still sucks pretty bad. You can try and make it a bit more consistency through a wrapper layer around WSGI entry points, but ultimately you possibly still need framework developers to come to the party. Usually though they don't see this sort of issue as a priority or even necessary though. Graham > Tang, > > I'm not an expert of the middleware development in Django but from what i > saw in the documentation it could be a great way to do that. Look at this > comment by example: > > "For performance reasons, middleware classes are only instantiated *once* in > long-running server processes; this means that you can't count on > __init__ getting > called every time a request runs, only once at server startup. > " > " > > -http://www.djangobook.com/en/beta/chapter16/ > > You'll need to test if it's true but there's a great possibility it would be > the case in real world experimentation. > > But if i was you i would really try twod.wsgi cause this guy is using > something that have bean used from time to time in the Pylons world where > this kind of use case is perfectly solvable. > > 2010/8/18 Richard Colley <richard.col...@gmail.com> > > > > > Why not call your "boot" code from settings.py? > > > On Aug 18, 4:05 pm, Tang Daogang <daogangt...@gmail.com> wrote: > > > hi, Emily, > > > > Let me introduce Scala/Lift as example. > > > > Every lift project has a file named 'Boot.scala', this file will only > > > be executed once when this project boots up. In this file, we can > > > write some initial codes to initial project and some userdefined > > > structures. > > > > Emm, that's it. I want to find one file acting like Boot.scala of Lift > > > within Django, but failed. If there is one file like that, I will put > > > my plugins registering codes into it, thus, when I type "python > > > manage.py runserver", it can be executed automatically and only once. > > > By it, my plugins can be registered when app boot up. > > > > Do you understand my meaning? Welcome suggestion. > > > > On 8月17日, 下午8时45分, Emily Rodgers <emily.kate.rodg...@gmail.com> wrote: > > > > > On Aug 17, 2:26 am, Tang Daogang <daogangt...@gmail.com> wrote: > > > > > > Dear all, > > > > > > Recently, I have developed a plugin system for my app, and I want to > > > > > register those plugins when my app boot up, this need to execute some > > > > > user defined codes (functions) in app boot procedure, I don't know > > > > > where insert my registering codes to, anyone can help? > > > > > > Thank you. > > > > > Hi, > > > > > I don't know how to help you, but I think it is because you haven't > > > > explained what you want to do thoroughly enough. > > > > > What do you mean by a plugin system, and what do you mean by > > > > registering them with the app on boot up? Are you talking about > > > > including another python module in your code? Or perhaps including > > > > another django app in your code? > > > > > Can you give us a bit more information (and maybe examples) of what > > > > you are trying to do. > > > > > Cheers, > > > > Em > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To post to this group, send email to django-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@google > > groups.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-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
