On May 9, 7:41 am, Ross Peoples <ross.peop...@gmail.com> wrote: > Just wanted to give an update: > > I moved one of my projects with about 10 modules over to the new import > method, and so far it's working perfectly. I should also mention that the > new method has greatly simplified the way I write modules. I used to have a > z_import_modules.py model that should run all of the local_import() calls, > then instantiate all of the objects in those modules. Now, my modules are > more like regular Python modules, which I import at the top of the > controllers that need them. This is very nice! > > I do have a few suggestions though, now that I've got some experience with > using this new method: > > Jonathan actually mentioned having a current.application Storage that would > store things like auth and db that are created in models. I would REALLY > like to see this. I still need to have my z_import_modules.py in order to to > set these things manually to current. I understand that it's easy enough to > set these yourself at the end of db.py, but having a standardized Storage > object with these variables would be better in the long run. >
If I understand.... you can already do current.db=DAL(...) current.auth=Auth(db) > My only other thing is: How much effort would it take to get the Storage > class to be imported when you call "from gluon import *"? The question is pollution of name space. Otherwise it takes nothing to do. What do people think about this?
