> > > What you really need to be successful is a singular set of tools, with > just about everything you should need to write a web app built in, > fully documented as if TG were a single project like Django as far as > the user is concerned. Abstract out all your dependencies too, there's > no reason I should be importing things directly from SQLAlchemy or > Genshi, I should be importing things like tg.database and tg.template, > even if they're only wrappers so that if and when those things are > changed I don't have to go back and update my code to the new > dependency. That also applies to documentation, putting "see docs on > Dependency X's web site" doesn't cut it. If you want to be the full- > featured mega framework, then I should rarely have to leave the > turbogears.org domain. >
Well, we aren't going to wrap the entirity of SQLAlchemy or Genshi or whatever, because that's a HUGE API to try to manage. But I agree we need to be doing a better job of managing that set of problems. I think we will likely need to create some new abstraction layers in a couple of key places in order to make the "full stack" approach work in a world where NoSQL and HTML5 local apps are busy changing the web framework landscape. Personally I'm still leaning toward the 3 way merger of BFG/ > Pyrmaid, Pylons and TG, with the 2 package concept Mark mentioned > (minimal-core vs full-stack). I've heard a lot of that in this thread. Sure there's been some feedback in other directions, but here and offline I'd say the majority of people are in favor of some kind of merger. And I think that the momentum that Pyramid has been gaining over the last few days since it's public announcement has been a very good thing. --Mark Ramm -- 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.
