My concern would be that I want it to be very easy to create widgets and wouldn’t want to sacrifice that too much for the sake of cross-framework sharing.

I’m expecting to see quite a few AJAXian and JavaScriptified (to use two crazy buzzwordish things) widgets. Some widgets already have considerably more markup than I’d want to do via string concatenation (though something like STAN could be reasonable). Look at TableForm for an example:

http://www.turbogears.org/svn/turbogears/trunk/turbogears/widgets/forms.py

By the way, TurboGears widgets/forms include the validation/conversion that’s necessary to go to/from Python (using the FormEncode package), and provide easy mechanisms for including JavaScript and CSS. Unless I continue to get sidetracked today, I should get two new screencasts up that talk in more detail about how forms work.

Once I’ve done that, it would be interesting to talk more about Zope 3’s widgets and how they compare. The turbogears.widgets stuff is definitely experimental, so I’m open to better ways of working, if they exist…

You are absolutely right in these key issues. By focusing on a singel stack that really works, you reduce the learning curve and improve productivity. You also improve maintainability of the framework, thus protecting the investment of the user community. Anybody who wants a custom tailored solution can roll their own and invest the resources neccessary.

My choice to create a prototype with TurboGears over Zope3, Django, Twisted etc. was:

1 Well defined framework and vision
2 Key technologies (MVC and SQLobject)
3 Up and running in half an hour
4 The promise of AJAX

TurboGears will hopefully be living happily side-by-side with some Zope applications.

Moreover I am very excited about your concept of widgets. It will be fun to see how they will work with SQLobject.

What I am hoping in the medium term is that it will be possible to migrate FileMaker Pro solutions to TurboGears with considerable ease, retaining the benefits of maintainability of FM PRO, whilst adding extensibilty that just isn’t possible with FM PRO. This would free a lot of resources and agony!

Keep up the excellent, focused, work!

“”"
the ability to have a form dynamically generated or statically generated for full hacking by a designer (usually you get one or the other),
“”"

I’m not sure what you mean by ’statically generated’. If you mean giving the designer the ability to render the widgets in the place they want, both the venerable Formulator which I wrote in 2000 as well as the new Zope 3 form system can do that just fine (see the hint: we’ve been doing this for a while in the Zope community). If you want to be able to hack actual widget HTML from within the form, I am curious to hear what your use case is; please let me know.

The ability to use Kid is a more serious objection, but can also be interpreted as a typical Not Invented Here response.I don’t find the use case of having to use a template language for widgets very convincing. For the scope of the HTML generated by the typical widget, generating HTML from Python with a few helper functions is sufficient, and a templating system may be overkill. Perhaps you can expand your argument here.

If you can gain a common pool of widgets shared between frameworks from the concession of not using your templating system where it may not be such a boon anyway, that might be very worthwhile to you, as you’d have a much greater community of widgets users. I thought this was the philosophy of TurboGears — don’t reinvent the wheel but profit from the code, experience and community of existing projects. I’m willing to spend some time trying to extract the Zope 3 widgets machinery so it can be used standalone if you’re interested in at least considering it.

Ben: Without a doubt, different people will have different opinions of which tool is the “best of breed”. I think Kid is the best language for generating HTML pages, and that is the #1 thing that templates do in webapps. It provides *many* different ways to compose templates from different parts, and I haven’t particularly been missing any features from Cheetah (which I’ve used heavily).

Rather than prematurely optimizing by choosing a template language that I do not think is as good, I started with Kid with the knowledge that Python provides a great many ways to improve performance and that we’ll be able to do so.

I should also note that even if there are people turned away because they don’t like Kid, there are many others who *do* like Kid quite a bit and have said so on the list.

All of that said, there’s no smiley needed on your last point. It is indeed my intention to maintain TurboGears with best-of-breed components. If I become convinced that a component is not the best and that its deficiencies will not be taken care of readily, I would start working out a migration strategy. That’s what I meant by “maintain use of” the best of breed.

The performance of it is also rather problematic (http://trac.turbogears.org/turbogears/ticket/28), as with even a moderate amount of markup it becomes as slow as Plone. I’m sure this will likely be remedied eventually, but I’ve already seen some people skip TurboGears entirely due to its abysmal templating performance (and lack of sophisticated caching).

Of course, even with its speed up to par, the features it has are lacking considerably in the face of Cheetah or Myghty. It’s not just about adding one or two missing features, its missing a ton of great features that both these other template languages have thanks to years of use by demanding users. (While Myghty hasn’t been around years, its benefitted from the experience gained using its Perl ancestor, Mason)

On the other fronts, ORM, controller, etc. I think you’ve done a great job picking obvious best of breed components. SQLObject is without a doubt the largest and best-of-breed ORM on Python, and CherryPy is obviously out front for its part.

Out of curiosity, if someone comes along and starts showing how much more speed and power you get from TurboGears thanks to a more full featured “best of breed” template language, would you ever consider switching TurboGears to it?

Instead of reinventing the widget wheel again, perhaps we can work together on some of this? Of course that would mean your widgets wouldn’t be using kid and ours wouldn’t be using ZPT (they typically aren’t anyway), but if we can create a bigger pool of reusable widgets that sounds good to me.