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! Any ideas? ~br On Jul 10, 10:49 am, Mike Orr <[email protected]> wrote: > On Sat, Jul 10, 2010 at 10:14 AM, BrianTheLion <[email protected]> wrote: > > Thanks for the reply! > > >> Can't you turn it around and have helpers.py import the items from the > >> other module in the normal way? These aren't "dynamic" in the sense of > >> changing at runtime. Or are they? > > > I was hoping to find a way to make my module-specific helper functions > > available as attributes of h without the user needing to go around > > editing files. Ideally, they would just drop the module into the > > mypylonsproj/lib directory and they'd "magically" have access to the > > functions in their templates without ever having to edit lib/ > > helpers.py. > > Is "from myapp.lib.greatlibrary import *" that bad? If they're making > a Pylons application, they're already doing a lot of file editing. > > If you really want to do what you describe, you'd have to import > 'helpers' relatively because you don't know the name of the > application package above it. Relative imports are sometimes > unreliable, and Python is moving to the leading dot syntax in I'm not > sure which version. > > > I see that use of pylons.url has replaced use of url_for as the best > > practice, anyway. It's not available in the template context as > > "h.url" but rather as just "url." > > Yes > > > I'm thinking that I may be able to > > overload url to get the functionality that I want. > > Where's the code > > that loads it into the template namespace? > > See pylons.templating. You'll have to write a render_mako() function > that injects your own 'url' into the template. > > Or if you want 'pylons.url' to work differently across the board, look > at the source for RoutesMiddleware. It instantiates a URLGenerator > object and puts it in the WSGI environ. Pylons assigns that to > 'pylons.url'. So you could replace 'url' in middleware, or perhaps in > the base controller. > > -- > 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.
