Those are all really good points, and I appreciate the time it takes to think things through, and ask intelligent questions. So, I'll do my best to address them.
First, you bring up the question of what the added flexibility of Pylons integration is going to cost you in terms of learning curve. I won't pretend that there will be no learning curve involved, we are making some changes, and there will be a few areas of backwards incompatability. But you won't have to learn to write Routes yourself -- we have a single default route, that will call your root controller, and provide the same CherryPy object dispatch functionality that you are used to. You won't have to learn WSGI either, because your controller methods will return dictionaries, just like they always have. At the same time for those users who have expressed a desire to map their application to a legacy URL schema, or who have had to hack up strange default methods to get what they want, Routes will be available to them. No cost to most users, extra benefit to a few who need it. The same will be true of all the caching, session, and WSGI middleware stuff that's out there. If you don't need it, it won't change the way you develop TG applications. And if you do, there will be simple ready-made solutions available to you. We still plan to provide an integrated set of libraries to make web application in TurboGears look pretty much the same as it always has. As for the CherryPy vs Paste page you point to, I agree with some of it's comments and not with others. I don't have time to to write up a full response, but I think it's the wrong comparison for us. Pylons offers a nice layer of abstraction on top of paste, and TurboGears 2 is going to offer a layer on top of that -- so the fact that you don't normally want to mess with all the lower level features of Paste yourself should be perfectly fine. We'll be giving you ObjectDispatch, a standard Response Object, turbogears style config objects, and all of the conveniences you've grown to know and love. It's just that we'll be borrowing Pylons implementation, or building our own rather than use CherryPy's. Of course that leads to your other implied question, why not just use CherryPy. This is a harder quesiton Pylons and CherryPy offer us a lot of the same features in different ways. And we tried going both ways, but in the end it turned out Pylons worked better for us. There's a lot of good design and engenering work in CherryPy 3, and I wish that we were able to build version 1.1 on CP3 as we'd originally planed. But due to some internals in TG 1.0, that was more difficult than anybody anticipated. Hopefully that answers most of your questions. If you have more, please let me know and I'll see what I can do to clarify things even more. --Mark Ramm On 6/28/07, Thomas Crawley <[EMAIL PROTECTED]> wrote: > > 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 > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
