Turbogears2 has been updated to include Routes integration by default. If you have existing turbogears2 projects they should continue to work, but you may start getting deprication warnings.
To remove those warnings, you will need to update your project. 1) Use TGController rather than the depricated TurboGearsController for your root object 2) Update environment.py to setup a make_map function. You can see an example of this a quckstarted template. TG2 now includes a make_default_routes_map function which you can just use. 3) Update middleware.py to add routes middleware to your application's stack. 4) Update middleware.py to make your application a PylonsApp rather than the former TurboGearsApp. I'm expecting that I will be doing a lot of changes to middleware.py and environment.py this weekend, and I'll probably remove the TurboGearsController and the TurboGearsApp by the end of the month. My plan is to make the configuration files much more clean, and to provide TG namespaced aliases for some of the current imports, so that there isn't so much boilerplate configuration code in the quickstarted template, and so that the code that's there is as easy to follow as possible. --Mark Ramm On Tue, Feb 19, 2008 at 11:23 AM, Mark Ramm <[EMAIL PROTECTED]> wrote: > So, here's the question of the day. > > Alberto and others want to have routes integration in TG2, which I > think is a worthwhile goal. > > An earlier version of TG2 had routes integration by default, with a > standard pre-configured route that wired up the expected object > dispatch behavior of TurboGears. > > We contributed this to Pylons, and it works fine there. But we > decided in a previous sprint that it would be worth it to remove the > Routes dependency from TurboGears 2 entirely for those who don't want > it. This also allowed us to move away from the reinstantiate the > controllers on every request model of Pylons, which had the potential > to create some additional latency -- particularly on very large > projects with big controller object trees. > > But it turns out that we've gone back to re-instantiating controllers > on every request, and it seems that there's enough desire for routes > integration that it might be worth re-visiting that decision. > > The arguments for reverting to the earlier Routes integration method would > be: > > 1) Routes provides a valuable "escape hatch" strategy for times when > object dispatch isn't as easy as you'd like it to be > 2) You would be able to setup routes, and mount pylons controllers > directly in a TurboGears project. > 3) We can use Routes to mount arbitrary WSGI applications at > particular URL's without complicating our object dispatch system > 4) TurboGears and Pylons can share more code, and we can use the > Pylons base-app rather than creating our own > 5) You can break up your app into smaller controller groups, so you > don't have to instantiate the whole tree on every request. > > The arguments against it are: > > 1) everybody has to have routes installed > 2) there is a little bit of extra code to set up the default URL > dispatching route > 3) route checking will happen on every request -- but this is very, > very, very fast. > 4) routes is going to change in the near future, so we'll have to > update our one route to fit that new system > > > So, I'm thinking that we should to go back to the earlier version, > because it provides several important features (mounting WSGI apps > easily, providing escape-hatch flexibility, and performance > improvements for large projects) without much downside. > > One particular thing that I'm working on right now that would need to > be done in different ways depending on how we do this, is allowing us > to mount AMF middleware inside a TG2 app easily, so that you can call > it directly from a Flex app. I don't think this particular use is > critical, but it does highlight the fact that there's currently no > dead-simple way to mount WSGI apps inside a TG2 app -- and I do think > that general use case is critical. > > My plan for implementing this will be to change the way new > quickstarted apps work right away, but not remove the > BaseTurboGearsApp, or any of the current code for a month or so. > That should provide time for TG2 users to migrate to the new way, and > not interfere with new projects. Then in march we can remove this > depricated code. > > Any thoughts? > > > --- > Mark Ramm-Christensen > email: mark at compoundthinking dot com > blog: www.compoundthinking.com/blog > -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
