Thanks for the mention, Mark! ;)
One of the reasons why I abandoned TurboGears was due to, at the time, an
insufficient number of knowledgeable devs able or willing to assist with three
specific problems I was having; one, a feature regression, which prevented me
from using TurboGears for my big CMS project. Other issues had been niggling
at me, and interestingly, documentation was only barely one of them.
I’ll summarize my issues, most, if not all of which have been resolved since I
left nearly 2 years ago, and then describe WebCore’s philosophy:
1. Easy to get started, mind-blasting to debug. I had a problem in the
dispatch mechanism of TurboGears, and it was literally easier to write my own
from scratch and create a new framework in the process (~300 lines) than it was
to try to figure out where in TurboGears my problem originated.
2. Dependancy graphs. TurboGears, as mentioned by several others, depends on
some packages which don’t make sense for all applications. The transaction
manager from zope (with the extra package for SQLAlchemy), specific repoze
components for authentication/authorization which I have never used, etc. The
last time I checked TurboGears 2.0 had 42 hard dependancies. Chris tells me
this has been improved in 2.1 or 2.2.
3. Flat is better than nested. I never really liked the idea of TurboGears
being based on another ‘megaframework’ like Pylons, which is in turn based on
something else, etc. If a framework brings together separate components, they
should be separate, not inherited from. That’s the wrong type of dependancy.
4. As voiced, some of the choices for ‘best of breed’ have been less than
perfect. (Kid→Genshi→Mako→Jinja2, etc.)
5. Overriding defaults was devilishly difficult; changing the template from
within the method, due to the passing of the template to @expose was hard.
Changing the mime type required (at the time) the use of “CUSTOM/LEAVE” as the
mime type in the @expose decorator.
When I wrote WebCore I wanted to write what, in my mind, was the “perfect web
framework”:
1. One that does not demand much, if anything, of the client application. This
means no hard dependancies on /anything/ that is not utterly required for
operation. WebCore doesn’t install any database layer, templating engine, etc.
as a direct dependancy. (WebError uses Tempitia though.) Core dependancies
are: Paste, PasteDeploy, PasteScript, WebOb, WebError, and alacarte.
2. Any built-in feature should be optional (authentication/authorization) and
minimal. WebCore’s authorization predicate system only declares Anonymous /
Authenticated predicates and some helper classes so developers can easily write
their own. It does not care what database or other storage mechanism you use,
it uses callbacks into your own code. The login form (if used) is up to you.
Etc.
3. Hello world performance is important. I was ridiculed for my hello world
comparisons between frameworks set to their minimal configuration. However,
hello world tests do provide useful information: this is as fast as the
framework can go. Applications built on top of the framework can only get
slower than this.
4. Smart dependancies and automatic feature negotiation. If you have Beaker
installed in your virtual environment, Beaker becomes available for sessions
and caching. Middleware that requires other middleware automatically negotiate
for presence in the WSGI stack; e.g. if authentication requires a database
session, authentication will be inserted ‘deeper’ into the WSGI stack
automatically. I stole this idea from the uses/provides/needs initialization
script system from Gentoo Linux.
5. Simple projects. When I first left TurboGears and saw WebPy, I loved the
simplicity of getting started. A single file, no package, etc. WebCore
follows WebPy’s example here. The core WSGI application is in WebCore itself,
not generated from a number of files using callbacks into the framework in the
client application. A freshly quickstarted TG application has numerous files
in numerous folders, most of which you can not touch until you know exactly
what you are doing without risking breaking your app badly. (A framework
should not require effectively unalterable code be present in multiple client
apps, it should be in the framework.)
6. Simplified, Pythonic code. Decorators are nice, but hard for new
programmers to grok, especially when the decorator doesn’t decorate, it
registers callbacks or data in a central registry. That’s weird. ;^) WebCore
follows Python in automatically preventing access to underscore-preficed
methods. Don’t want something exposed? Mark it “soft-private” by prefixing
it. (An optional @template decorator is provided, however.)
7. Returning tuples is a great idea. (template_name, data, engine_options) or
(template_name, data) as return values (without the brackets, even) looks nice
and solves the dynamic template selection issue I had.
WebCore 2.0 will be Py3K compatible without automated code modification. It’ll
straight-up install on any version of Python greater than or equal to 2.5.
It’ll also support “my flavor” of WSGI2, a standard which doesn’t technically
exist yet, while maintaining backwards compatibility. I already have a WSGI2
development HTTP server working. WC2 will switch away from WebOb, WebError,
and Paste to marrow.* packages for the few features WebCore uses from these.
(Web server, configuration files, simple command-line scripts,
request/response, and error handling.) Each of these packages should be < 50KB
and have few to no external dependancies, and all work on Py3K. They will all
follow the same “simplicity, minimalism, and soft dependancies” style.
TurboGears needs to simplify, organize (esp. documentation), and pimp itself.
In terms of legacy 2.0 code, forking Pylons and maintaining an in-house version
may be required, but it’s hardly optimal. That’s a large code base currently
maintained by a differing circle of developers. There may be overlap, but
it’ll still make TG dev’s lives harder. :(
Chris Perkins has made some interesting packages from the TurboGears codebase;
at last year’s ConFoo he extracted the object dispatch mechanism from TG into a
package called Crank. This, I think, is a good direction to head in. Small,
light-weight, task-specific, 100% unit tested, well documented dependancies
would make working with, and more importantly /on/ TurboGears much nicer and
easier.
My $2.15, (Tank Girl reference)
— Alice.
P.s. I don’t mean to troll or inflame anyone; I still actively use TurboGears
on several ongoing support projects including one that is quite significant in
size. The above is just my, perhaps outdated, personal thoughts. Standard
disclaimers apply. ;)
--
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.
