On Sat, Jul 10, 2010 at 2:57 PM, BrianTheLion <[email protected]> wrote: > Thanks, Mike! > > For the sake of progress, I decided to just go ahead and edit lib/ > helpers.py so that it imported my own module's helpers as recommended: > > from mylib.helpers import * > > An interesting problem arose. My module's helper functions rely on > settings in development.ini that apparently haven't been processed > yet. When lib/helpers.py gets executed, dir(pylons.config) gives: > > ['pylons.c_attach_args', 'buffet.template_options', > 'pylons.request_options', 'pylons.paths', 'pylons.environ_config', > 'pylons.db_engines', 'pylons.strict_c', 'pylons.h', 'pylons.package', > 'debug', 'pylons.g', 'buffet.template_engines', > 'pylons.response_options'] > > No application-specific settings at all!
You can't count on pylons.config being iniitalized at import time. That happens when PylonsApp is called in middleware.py, I think. What you need to do is put the code into functions that will be called from controllers/templates, not at the top module level. Then pylons.url will be ready. If you want to do initialization at application startup, you'd make an init function and call it in environment.py, similar to how SQLAlchemy is initalized. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en.
