Hi, I am an application developer and I have used TG and I am very happy with it. I find it very usable and flexible enough to meet my needs. I really liked the fact that you could type "tg-admin quickstart" and get going. This is in contrast to many Java web frameworks which I had worked with previously which had a steeper learning curve and less usability.
There is a great deal of discussion about interacting with other components but what I would really like is "canned" functionality with sensible and integrated defaults and components rather than a more loosely coupled framework. I scarcely have the time or bandwidth to grok all the features of TG. My focus is on Rapid Application development rather than assembling the Framework which I am going to use from disparate libraries. Each time a new library is introduced into a framework must be learned and managed etc. I don't see what Routes, Pylons etc are buys us in terms of application development. I want to work with TG components and use TG as an Application Development Framework. I don't want to have to re- invent or re-learn TG skills every 6 months. I am happy enough with CherryPy dispatching and architecture. What is the status of CherryPy in all of this ? I have been reading some of the discussions on the Trunk list and it is not clear to me why CherryPy is being jettisoned especially when I read: http://www.cherrypy.org/wiki/CherryPyAndPaste which is partisan but raises points about application developer ease of use which I do not see answered elsewhere on the internet and in discussion groups. I particularly value the illustrations of the pythonic nature of CherryPy vs Paste/Pylons etc There may be advantages in terms of ease of deployment to using Pylons Paste etc but I don't see them. The only real preference I have is for SQLAlchemy over SQLObject. I think that the inclusion of SQLAlchemy is a real win but I would like to see a later version of SQLAlchemy being used in TG. Mark, I see that you are working on the book. :-) Thanks for all your efforts on Turbogears. Tom On Jun 27, 8:30 am, "Mark Ramm" <[EMAIL PROTECTED]> wrote: > Recently there have been a number of requests for more clarity about > the future of TurboGears, and since I've been involved heavily with a > couple of experimental projects designed to help us explore our > options, I'd like to help clarify things as best I can. > > A bit over a week ago several of us decided to get together in Atlanta > this past weekend and hack on an experimental Pylons/TurboGears > integration project. We wanted to discover if we could re-implement > the TurboGears API on top of paste+pylons in a way that would make > TurboGears better. > > The goal was not just to re-implement things, but to see if that > re-implementation actually improved the readability, flexibility, and > ease-of-mantinance of the TurboGears project. In other words, we > wanted to make TurboGears: easier for new developers to work on, > easier for us to maintain, and more flexible so we can take advantages > new python web developments in the future. > > If you're interested in the details of the sprint, I blogged about it, > and you can read it at: > > http://compoundthinking.com/blog/index.php/2007/06/27 > > On all counts, I think we can now say that this experiment has been a > huge success. And after lots of good discussion with Alberto, Kevin, > and Ben Bangert from the Pylons project, the way forward is now much > clearer. The results of the sprint will become the basis for > TurboGears 2.0. > > To make life easy for people who want to install TurboGears 2.0 > alongside the current version we will be creating a new package called > tg for TurboGears 2.0. And Alberto is planing to promote it out of > the pygears branch into trunk today. > > The new tg package will implement a very large percentage of the > current TurboGears API, and thus is intended to provide an very easy > upgrade path for current TurboGears users. In particular current > controller code should be very simple to port, and Kid, Genshi, > SQLAlchemy, and SQLObject code will be supported, so most of your > template and model code will require almost no changes, or will be be > usable as is. > > There's still work being don on TurboGears 2, and it's hard to predict > a release schedule in open source projects. But if you pressed me I > would say that I expect to see a beta in the next couple of months. > It could be earlier, it could be later... If you're the adventurous > type and don't want to wait until then can check it out of subversion > today, but expect a lot of rapid changed. > > At the same time the turbogears development team will continue to > maintain and support TurboGears 1.x for our current users. We want to > accommodate users who create new TG 1.0 projects for a long time, but > we also want to make it easy for those who want the latest and > greatest stuff to get started with TurboGears 2.0 as soon as possible. > > There will be a TurboGears 1.1 beta release in the next few weeks, > which will fully support the current API, and will switch the default > templating engine from Kid to Genshi, and the default ORM from > SQLObject to SQLAlchemy. This release will not include an upgrade to > CherryPy 3, because that has required backwards incompatible changes, > and has taken much more work than expected. If someone wants to take > up the standard, there may be a TurboGears 1.2 wiith CherryPy 3 > support, but as far as I know nobody had volenterred to do this. > > And of course, SQLObject and Kid will remain supported in 1.1, to give > us full backwards compatability with current applications. Catwalk > and Model Designer will remain SQLObject only applications in 1.1. > > And that brings us back to TurboGears 2.0. In addition to the current > TurboGears API, the new tg package will support all kinds of new > features that will make our user's life easier. Many of these > features are the direct result of our integration with Pylons, because > we'll be getting access to a lot of great stuff they've already done. > And we'll be sharing almost all of our infrastructure code with > another group of great developers. > > The end result is that TurboGears users that have sites that need to > scale up, will have have access to world class caching options > (including memcached support), as well as a number of other > performance enhancing features and options. For the majority of us > who are more interested in rapid development, and deployment > flexibility, than raw performance, TurboGears 2 will include all kinds > of new features. TurboGears 2 will also implement a more flexible > Object Dispatch system, as well as direct Routes integration, so it > will be even easier to get exactly the URL's you want. > > There's a lot more going on too like 1.1 TurboGears 2 will make Genshi > and SQLAlchemy the defaults because they provide a better experience > for the majority of web developers. We won't be forcing our opinions > on anybody, and other ORM's and templating engines will be supported, > but we'll be focusing all our documentation effort on those defaults. > We want to make very sure that our documentation tells a clear and > compelling story about how this stack of components makes web > development easier. > > At the same time, we'll be working to support people who want to > develop and maintian sub-projects for automatic CRUD (like Catwalk or > the Django interface) outside the TurboGears 2 core. Our hope is that > these tools will be broadly usable by anybody who is working withing > the context of a framework that implements the Web Server Gateware > Interface standard. Ultimately I think Pylons, TurboGears, Paste, > Zope, and all kinds of other python web developers toolkits will be > working together on creating great tools for rapid development. > > Thanks to Pylons, Paste, SQLAlchemy, Genshi, Babel, and a whole host > of other contributions from around the web TurboGears development is > getting easier and more fun. I for one, am really looking forward to > all the good things that are in the pipeline! > > I'm looking forward to some spirited discussion of the TurboGears 2.0 > plan, and the plan for TurboGears 1.1 on the TurboGears trunk mailng > list. > > (http://groups.google.com/group/turbogears-trunk) > > -- > 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 -~----------~----~----~----~------~----~------~--~---
