On 6/11/06, Collin L <[EMAIL PROTECTED]> wrote: > > Doing some simple PHP today made me realize how much I am beginning to > loathe cherrypy's autoreload process involved in editing controller.py. > > Make edit... Save file... Wait for cherrypy to reload (at least 6 > seconds)... Refresh page.
I have definitely given this more than a little thought. For my own development, I like to stress test-driven development. That means that more often than not I'm not waiting for server restarts. I'm just running tests. I head over to the server to sanity check that things work and work on the visuals. But, I know that's not ideal for everyone. And, it's not even always ideal for me. One thing that just popped up yesterday is a simple way to speed up "import turbogears" in the case where you're not using every part of TG. This should make running tg-admin and tests faster. But, for many apps which *do* use much of TG, there won't be a big improvement. Because we use classes and instances to represent the URLs, the reloading problem becomes tricky. The trouble is finding the instances and reliably updating them. The current autoreloader is trading reliability for speed... since it restarts the process completely, you *know* it's going to work. If we tradeoff some potential reliability in order to handle the common case quickly (which is probably a good tradeoff for development), we can likely get a big speed up. Here's three candidate approaches: 1) watch for changes to your project's modules (as we do now). when something changes, reload() all of yourproject.* modules. create a new root instance, copying the __dict__ of the original. (Note: this has a problem if any of those instance variables are one of your classes... that's not the common case, though. we could go rummaging around in that __dict__, attempting to update any instance we find that is from yourproject.) 2) Use a metaclass for updating your controller instances: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 3) Try out Thomas Heller's reloading module: http://aspn.activestate.com/ASPN/Mail/Message/python-list/907876 (with the bugfix) http://aspn.activestate.com/ASPN/Mail/Message/python-list/907945 The most radical approach would be to change to a function oriented code, rather than class oriented code. But, we lose the advantages of OO if we do that, and I think the OO nature of it will become more important when you start being able to easily install and reuse TG apps. Kevin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
