hi all, i'm not using turbogears for real world applications but there were some in-house applications that i have built with tg2. so, i'm not an active turbogears user but i have sympathy for it and i really like it.
i have picked pylons for my start-up instead of turbogears because turbogears is built on pylons so i have thought why not use the parent directly when they both do the same and considered the possibility of encountering performance issues as it is layer over layer. the main difference between pylons and turbogears is the widgets for turbogears, like admin and toscawidgets. the question here is, when developers and managers would pick turbogears for their next web application? - when it performs really good and scales - when it is easy to start - when it is extendable - when it is still easy when things are a lot more complex than the beginning - when the app developed with it is re-usable - when anything searched on the documents can be found - when anything asked in the mailing list or the irc room is answered now, lets take a look at those. - turbogears performs really good and scales. how did i learn that? because it is being used on sourceforge.net. from a slide of mark ramm. not in the turbogears web site. - turbogears is easy to start. how did i learn that? from the quickstart. - turbogears is extendable. that is primarily because its python. :) - turbogears is still easy when more complex things needed to be done. how did i learn that? because it doesn't bother me working with turbogears when i build some kind of social network with it. (yes, i have tried it.) - turbogears apps are re-usable. still, python. - turbogears documents are complex. they are not organized. many things are out there in the docs but they don't even show up in the search, let alone the document organization. hopefully this would change with the sprint. - any turbogears related question is replied in the mailing list or irc. i had no questions left unanswered. as you can see the only thing, as a developer, i did complain about is the documentation. turbogears documentations exactly should be like django's, as in the organization schema i mean. those were "when would one choose turbogears" but we also have another question. it is "why would one choose turbogears over django, pylons or web2py". the answer of that question, i believe, is simple. it is all about being better. having better options, having better tools, having better support. so in order to be chosen and used in real world applications, in my opinion, turbogears doesn't need to merge with other frameworks or opt-in any other. unless of course, the new base is better than the old. thanks for reading. :) On Oct 29, 4:33 am, Mark Ramm <[email protected]> wrote: > So, I got the news that Pylons2 was going to be built on repoze.bfg, > and among other things, that got me looking at various options for > our future. > I decided we could: > > * Build on top of pylons on top of bfg, > * Build on top of bfg directly > * Take the microframework (which had been being taken by pylons) and > move it back on as a core part of TG. > > Jonathan Lacour did a great little experament at the last TG sprint on > where he investigated the last option: > > http://github.com/cleverdevil/pecan > > Chris Perkins showed me something he and Allice have been working on > which is pretty similar, but more mature: > > http://www.web-core.org/Home > > These approaches help in some ways, they reduce or shift our > dependencies, and provide possible futures. But they would both be > TG3 type events. They'd be much smaller than the tg1 to tg2 > transition, but there would still be a number of small > incompatibilities. I'm more than willing to do that kind of thing, > but am a bit hesitant about them if we're not absolutely sure that > this is the right thing to do for our users. So I was also been > seriously thinking about forking Pylons 1 to keep tg2 going long term > on that platform. > Pylons/bfg sprint > > As I was thinking all that through, Ben Bangert contacted me to let me > know that there was going to be a bfg/pylons sprint, and I flew out at > the last minute to check it out. > There was a lot of discussion about how bfg and pylons work, a bunch > of discussion about how we can all work together better. > > The point I emphasized a bit was that Django is doing a great job of > marketing, and the current situation is something like this: > > #1 Python web Framework > ---> Django > > #2 Python web framework > ---> TurboGears or Pylons or repoze.bfg or flask or... > > Given the number of choices for the second position, people are > defaulting to Django because they don't know how to choose beyond > that. > All three frameworks have been talking about how to build higher level > abstractions (oauth support, admin tools, a widget system, etc) so > that we can better compete with Django feature for feature. > > So, it was proposed by Ben, that we just all go ahead and figure out a > way to do what Rails and Merb did and stop building on top of one > another and find a way to actually merge our three communities. > Merger Talk > The merger discussion boiled down to a couple of questions: > > Is there a common core that we can all agree on, and build around? > Are we willing to make the kinds of adjustments and compromises to > actually make this happen? > > So, we did a lot of talking, a quite a bit of experimentation, and > more talking, and after a bunch of fits and starts, I think we came to > the conclusion that, if our communities were interested, yes we could > make this happen. > > We decided that this experimental package would be created with > several core TG philosophies in mind: > > We aim to create a full stack framework that gets you started quickly > > We will take advantage of reusable components, and to use the best > tools available > > And would use several common turbogears idioms by default: > > * expose decorators > * returning a dictionary > * simple controller methods > > We also got at least started on support for sqlalchemy, genshi, > turbojson/jsonify, and many other very common turbogears tools. > There's a new experamental package called Pyramid which is the result > of a lot of that talk and experimentation: > > http://github.com/Pylons/pyramid > > It has support for us to build in object dispatch, already supports > pylons style routes, and a third kind of dispatch which I'm going to > call site-tree traversal, all of which are backwards compatable with > our existing frameworks. > > And better than that we created a "legacy" handler that allows you to > mount existing pylons or turbogers (2 for sure, and probably 1) > applications directly inside of a Pyramid app. People can then > migrate bit by bit as the feel the need. > > My thoughts on what to do > ---------------------------------------- > > I went in thinking a merger would require giving up too much. > > But ultimately I found that the repoze.bfg and pylons folks recognize > the same need to build a strong framework for application code re-use, > and have begun looking at a more full-stack approach on their own. > And given all of our agreement about the best approach, I quickly > changed my mind. > > Chris McDonough and Ben are very willing to work with us to achieve > the very goals that TurboGears was founded on. In a real way they > are being assimilated into Kevin's original vision for TurboGears -- > just in a new package. If we join with them I think we can and should > take the lead in creating the next generation of high level tools that > will directly compete with the best that the django community has to > offer. > > I left the sprint excited about the new blood that this would bring to > the TG developer community And I'm not sure how much we can afford > not to band together to build something awesome. It will require us > all to make some sacrifices, let go of some code that we love, and > embrace new approaches to some of the problems we've been facing. > But in the end, I think we will find that we're working with a much > larger group of talented python web experts to build a framework with > greater potential and greater reach than what we can do on our own. > > And perhaps most importantly, it will be an opportunity for us to take > control of a much broader spectrum of our dependencies, so we don't > get left behind by abandoned projects, etc. And that control will > give us a much better ability to document, support, and prove the > value of our component based approach to web development, and in the > end, that's what I care about. Well, that and getting things done, > which I think will be a lot easier with Ben, Chris, and all the other > pylons and BFG developers on board. > > No decision has yet been made, and I'm very interested in hearing what > you all think about all of this. Let the fireworks begin! ;) > > -- > 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.
