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. 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." 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? Cheers! ~br On Jul 8, 11:31 am, Mike Orr <[email protected]> wrote: > On Wed, Jul 7, 2010 at 7:02 PM, BrianTheLion <[email protected]> wrote: > > Hi, > > > First of all, despite what it says in the documentation, > > routes.url_for is indeed available as h.url_for in my templates on > > v0.9.7. > > > I haven't touched a thing in lib/helpers.py. Is this now > > "fixed" in v1.0? If not, when can we expect to have to start manually > > adding helpers per the documentation? > > > I ask because I am interested in *programatically* adding some helper > > functions to h for use in my templates. I'm writing a module that will > > live in myproject/lib and I'd like to have this module's __init__.py > > make the functions available without any further intervention from > > module users, e.g., without them having to edit lib/helpers.py. In the > > past, this would have been as easy as > > > <code> > > from pylons import h > > If this works in 0.9.7 or 1.0, it's an unintended feature. The proper > syntax now is: > import myapp.lib.helpers as h > > > h.a_helpful_fn = my_helpful_fn > > 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? > > In any case, if you think you must put things into 'h', it's OK to do > so. But do it through 'myapp.lib.helpers', not 'pylons.h'. > > As for your general question, Pylons 0.9.6 and before had a more > magical 'h', and the default imports in helpers.py imported the rails > helpers from WebHelpers. In 0.9.7 we got out of the business of > assuming which helpers you'd want, so you have to put them into > helpers.py yourself. But of course, existing applications would keep > whatever imports they had. Also in Pylons 0.9.7, pylons.url was > introduced to replace h.url_for, which depends on an ugly global > singleton. In Pylons 1.0, support for url_for was dropped (although it > may not be so in your app, depending on a middleware.py setting). > pylons.h should have been dropped in 0.9.7 but it may have been > overlooked. ``render_mako()`` imports 'h' into the template namespace > via ``pylons.templating.pylons_globals()`` and a config variable > "pylons.h" (a string key). > > -- > 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.
