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.
With ice season approaching, I had to find a solution to this problem, as I really love climbing ice, it brings you to some pretty spectacular places. At Plonecon this year, I saw two people with the same unusual keyboard, a 
as the fact that the “b” key is on the left hand. I’ve been typing that one with the right hand for as long as I can remember. When I look at how I used to hold my hands over the keyboard, I can see that the left hand is bent a little, which makes hitting the “b” key a little more difficult, which is why I probably did that with the right hand. Also, I used the left shift key exclusively. I still struggle with that, but I am getting a better about using the right one as well, you just have to take a little more time when typing capitals to be able to use both. (This would really suck if I was a JavaProgrammer)