>> - 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 :) > > Could we maybe write this as a "endware" that would be added to the > wsgi stack and would then receive the same params as any other wsgi > middleware? Please note that I am all for the functionality you are > talking about, and am just trying to feed a technical discussion in > this mailing list to see if other people out there would be interested > to give some input... hint, hint, hint...
I think we should support it the variable providers thing, though I think that we may want to think about our options here. I'm not sure about the middleware idea, because what we're doing is just providing shortcuts to the template, which happens at the TG core layer. I think sticking a callable on app_globals, which we poll in the template variables setup phase to get a dictionary to throw in the template would work, and would be pretty similar to what we had in tg1. Moving rendering out into middleware would allow us to do the template namespace updating in middleware too, but that seems strange to me because the TG2 wsgi app (the core app) needs to return a list of strings, and I'm not sure what that list would include if the rendering happens elsewhere. I don't --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
