On Thursday 13 November 2008 23:48:33 Florent Aide wrote: > On Thu, Nov 13, 2008 at 11:44 AM, Diez B. Roggisch <[EMAIL PROTECTED]> wrote: > > So my question is - is there any reason why tg.url is not based on > > url_for, and if not, shall I come forth with an implementation? > > Could be interesting. url_for is coupled deep into pylons though and > some proper abstraction should be avoided to be able to not couple TG2 > to pylons because of that (we already have quite some coupling in > other places...)
Exactly because of that I don't see your point. tg.url will be the abstraction the user knows & uses. If we switch for whatever reason the foundation, it will be the abstraction to keep. I don't see how we could do otherwise. > > We also miss a way to stuff things into the template context. The > > oldturbogears.view.variable_provider mechanism doesn't work anymore, and > > currently only monkeypatching would help. Shall I implement a similar > > method as in TG1 into TG2? > > Could you not just stuff the desired functions/methods in your > applications app_globals.py and then access them from the template ? I haven't thought of that, yet there are a couple of reasons I'd like the to have the variable_provider-mechanism: - TG1 uses it -> people will look for it. - it is evaluated on a per-request-base AFAIK, which makes creating data dependent on the current request possible. - no extra namespace needed. Might be just a matter of convenience - but in the end, that's what we are here for :) Diez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
