So I have had a pretty long hiatus from working on dbsprockets, but I’m back… with a vengeance. So, I worked hard to get Rum working in TG2, but struggled my ass off and got nowhere. Left tangled in a web of peak-rules that I did not want to decipher, I began to think about dbsprockets again. I mean, were we really that far off from what RUM is offering?
The answer turned out to be no. All I needed to do was to replace the dbsprockets primitives with a class structure. This turned out to be about an 8 hour job. Not bad for a day’s work. And now you can do things like:
from dbsprockets.declaratives import FormBase
from myWebapp.model import User
...
class RegistrationForm(FormBase):
__model__ = User
__limit_fields__ = 'user_name', 'email_address', 'display_name', 'password', 'verify'
__required_fields__ = 'user_name', 'email_address', 'display_name', 'password', 'verify'
email_address = TextField
verify = PasswordField('verify')
__base_validator__ = Schema(chained_validators=(FieldsMatch('password',
'verify',
messages={'invalidNoMatch':
"Passwords do not match"}),))
registration_form = RegistrationForm()
class ATurboGearsController(BaseController):
@validate(form=registration_form.__widget__)
@expose('genshi:sproxtest.templates.register')
def register(self, **kw):
pylons.c.widget = registration_form
return dict(value={})
This turns out to be a much simpler way of handling forms, because now you can subclass to your heart’s content (for instance, make one base user form which you subclass for admin, registration, profile and login), or even come up with your own wacky WidgetSelector that chooses widgets for you and subclass as you desire. Here is initial documentation, which I will express in more detail at a later date when I have more time to do it the right way.
The simple fact is that you can customize form widgets with ease, limit fields to a set of fields, drop a few fields, basically anything you can think of to change how the database schema actually displays on the page. The same is true of field validators. Simply define an attribute of the class that has a validator, widget instance, or widget type, and dbsprockets will do the right thing. If you want to override both the field and the validator, all you must do is create a widget wit the validator attribute populated. The greatest thing is that your forms (and tables!) will change with you as your database schema migrates.
Right now I am keeping the primitives way of getting the values from the provider to populate the tables/forms. This is likely to change in the future. The primitive way of doing forms is now deprecated. I will be adding deprecation warnings to the code. Hooray!
Look for ajax support in the near future on both the view and data side of things. I have a clear understanding of ExtJS (2.0.1), JSON, and LGPL now and I am not affraid to use it. In the mean time, a dev version of dbsprockets 0.5 is up at pypi.

One of the more interesting things I have started to use with some frequency is Sphinx. Sphinx is a documentation system whichallows you to create webpages (among other things) with .rst files. It also grabs directly from your modules and inserts your docstrings (including your doctests.) It is great to have code which is not only documented, but also tested using nose. Look for a screencast from me in the near future on this one.
TG2 is actually nearing it’s second alpha release. I think This is the best release yet. I spent some time moving DBSprockets to pep-8 compliance, and the two things TG2 depends on (tg.ext.silverplate and tgcrud) are now both using the newest release of DBSprockets. I also released 

Now that I am back from vacation/new project hell, I have been able to release a new module for TurboGears, tg.ext.silverplate, which is a plugin for TG2 providing User Management and Profile pages which are customizable. This all fits under the TGTools domain, which has become a home for tg.ext.repoze.who (Authentication for TG2) and tg.ext.geo (An upcoming library for Geographical support in TG2). If you get a chance, you might want to check out the new
st desire to see put into action is that of a TurboGears CMS. There had been some work done last year by the guys at