I know I sound like a ludite, but I am trying to earn a living form developing software on Linux. I feel that I should point out that in the real world it is very difficult to get customers to move away from Windows to Linux. One of the advantages in the Linux world has been that the end users were not inflicted with continual updates to the software from Microsoft. Now it looks as if the open source world is going the same way. It does not help my cause when I selll my customers on this wonderful new package called Turbogears that uses SQLObjects, Cherrypy and Kid templates. Now before we have even finished the project I have to go back and say sorry, we got that wrong, it is now SQLAlchemy, Pylons and Genshi templates. But don't worry if we add Elixir as well, we can make SQLAlchemy look like SqlObjects! The dumb customer, who does not have religious convictions about which is the best web server interface, asks me what is the advantage to him of making all these changes? Any ideas? People never seem to learn that "if it ain't broke don't fix it". John
On 31 Jul, 20:04, "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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
