Karl Guertin wrote: >>First Class makes heavy use of WSGI and takes advantage of and builds >>on TurboGears 0.9's config system. I'm hoping that there are some >>others out there who'd like to work on this branch. > > > I have a rough understanding of what's going on in the branch, but not > a good one. I've got a few questions, some for me and some that I know > others will ask: > > How does this affect the long term viability of 0.9 based apps? I know > there is a lot of paste middleware that can be plugged in and am not > sure how apps I write now will translate into a brave new wsgi world.
During the sprint we tried as much as possible to not "fix" the tests, and just put in compatibility stuff, maybe fixing the test after we got the test to work in place. This wasn't fully accomplished -- I think the most notable cases were when we were implementing things as WSGI subapplications (which RhubarbTart is good at dealing with), and thus the response broke out of cherrypy.response. Now I'm thinking that even that was the wrong thing to do -- we should have serialized the app into the response object, then generated a WSGI response from that as normal. Though that adds more performance overhead, where there otherwise is little overhead to putting TG in front of a WSGI application. Maybe there's a middle ground there. The tests also do some trickier things since they are not making real requests, and so I'm hoping that they are actually harder to support than a real application would be. (Notably if you are using WSGI the test environment is nearly indistinguishable from a real web request, so there's less leaking). Some parts of TG that are more "infrastructure" -- like Identity -- aren't working in the branch. If you are writing your own infrastructure in that style (probably using CherryPy filters) then First Class will break things for you. But ideally you'll be using TG's infrastructure, which will be updated (in the future -- it hasn't been updated yet AFAIK). It's up to Kevin how the transition will work, but everyone wants to be careful about backward compatibility, and I expect the result to be pretty good. And I'm betting if you write an application with good acceptance tests that is open source(-ish), you can almost guarantee good backward compatibility for your app, because your app can become a very useful test case. End-to-end tests for real applications, built on things like twill or Selenium, are the best way for TG to really ensure backward compatibility. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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 -~----------~----~----~----~------~----~------~--~---
