I would use 1.0.3 with SQLAlchemy and Genshi right now, especially if the project is less than 2 months long. But if you're more comfortable with Kid or SQLObject, both of those will also be supported in the future, so there's no harm in using 1.0.3 with Kid and SQLObject. And the documenation will be a lot better if you use the current defaults -- there's even a book covering all that stuff ;)
Genshi's syntax is very, very similar to Kid with a few very useful improvements, and it has significantly better performance, so I think that one's pretty easy. SQLAlchemy is a lot more flexible, has a lot more momentum, and has a much larger development community behind it, and it has pretty great online docs too. So, you have your choice here too. If you are a bit more adventurous and you want to play on the edge you can certainly use tg 2 , and things should go pretty well for you. But you'll probably have to read code and docstrings more, because tg 2 isn't there at all in terms of documentation yet. The benefit to you is that we always need new developers and testers, and the more involved you are the more say you have in the way the future will look. I've written tg2 apps, and I don't think there will be too much API instability, but it's still a bit of a moving target. And a couple of things that we want (transaction handling middleware, some performance optimizations, etc) are not yet completed. Hopefully that helps provide the information you need to make your choice. --Mark Ramm On 7/31/07, TGTry <[EMAIL PROTECTED]> wrote: > > OK > What if I wanted to start a new project, would it be best to wait to > TG2.0? > Or use some hybrid approach? > > On Jul 31, 3:04 pm, "Mark Ramm" <[EMAIL PROTECTED]> wrote: > > Two quick responses: > > > > 1) Turbogears is not for everybody. > > > > 2) Elixir is not required, and it adds to SQLAlchemy only what > > SQLObject already had included -- and active record style development > > environment. > > > > I'm very aware that the TurboGears install process has become > > encumbered with too many requirements, and we're hoping to reduce both > > the TG2 codebase itself, and the number of installation requirements > > in TG2. However, there's a balance to be found, as we are very much > > in favor of code/library reuse, and that philosophy isn't likely to > > change. > > > > As for deployment, I think you'll find that high load web servers have > > trouble with mod-python due to the fact that you end up running so > > many python interpreters. So the separate-process python web server > > is not really a bad model. But, if you really want mod_python > > integration you can use a WSGI bridge: > > > > http://docs.pythonweb.org/display/pylonscookbook/Production+deploymen... > > > > Hopefully, mod_wsgi will be more widely deployed in the future (now > > that it's approaching a 1.0 release) and it will be another good > > deployment option for apache users. > > > > --Mark Ramm > > > > On 7/31/07, johnbrad <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > TG started out as a good idea as it looked like an easy way to get > > > into Ajax, but I now think it is getting out of hand - talk about > > > trying to hit a moving target! > > > To me it looks as if it is trying to see how many layers of software > > > it can pile on top of each other before it falls over. > > > Having Elixir on top of SQLAchemy which sits on top of the database > > > handlers is, IMHO, overkill. > > > And then you have all the complications of trying to get the > > > apllication to run behind a webserver such as Apache. Why not just > > > use modpython directly? If find that approach works fine. > > > Sorry, I must be missing something, all I want is a simple way to use > > > Ajax without all the complications of having to download nearly every > > > bit of software that has been written in Python > > > > > John Bradbury > > > > > On 28 Jul, 04:39, "Mark Ramm" <[EMAIL PROTECTED]> wrote: > > > > > As I understand it, TG will drop CherryPy, and adopt Pylons. Since > > > > > both frameworks are stacks of other python components, I am not sure > > > > > if I see the point. > > > > > > > A strength of both tg, and pylons, is that you can easialy swap out > > > > > different compents, right? So why not just put together whatever > > > > > components you want? > > > > > > TurboGears will be what it has always been, a stack of best of breed > > > > python components, wired together to provide a web experience that > > > > gets you started quickly, and provides a robust web development > > > > environment. TurboGears 2 will provide Pylons with a set of standard > > > > components, a new controller publishing API that is easier to get > > > > started with than Routes, a bunch of additional rapid web development > > > > tools, and a lot more developer attention. > > > > > > Pylons provides a robust WSGI stack, and a clean way to reimplement > > > > the TurboGears API in relatively little code. And since Pylons has a > > > > goal of being a framework that maximizes developer choices, people > > > > have been pushing Ben and the rest of the pylons dev's to make a well > > > > documented set of defaults, and to make the framework a bit easier for > > > > new developers to learn. > > > > > > In the new TurboGears+Pylons working together world, we're both able > > > > to focus on the things that have made our individual frameworks > > > > successfull in the past, and share development effort on lots and lots > > > > of things. > > > > > > So do answer your point, I think that working together with the Pylons > > > > folks benefits everybody in both user communities, and helps to > > > > strengthen both frameworks. > > > > > > --Mark Ramm > > > > -- > > 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" 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?hl=en -~----------~----~----~----~------~----~------~--~---
