> 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 <thomas.craw...@beacon-cs.com> 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" <mark.mchristen...@gmail.com> 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

> ...

> ead more »