[TurboGears] Re: Making form handling and widgets work

2005-12-16 Thread Kevin Dangoor
*sigh* Things have been very disruptive for me outside of work for the past few days. I have a feature to cleanup and two more devcasts to do that will make some of these things clearer. I'll see what I can clarify below and we'll see if the direction I was heading works for you. On 12/16/05,

[TurboGears] Re: Making form handling and widgets work

2005-12-16 Thread Jared Kuolt
On 12/16/05, Kevin Dangoor [EMAIL PROTECTED] wrote: *sigh* Things have been very disruptive for me outside of work for the past few days. I have a feature to cleanup and two more devcasts to do that will make some of these things clearer. I'll see what I can clarify below and we'll see if

[TurboGears] Re: Making form handling and widgets work

2005-12-16 Thread Wavy Davy
On 16/12/05, Jared Kuolt [EMAIL PROTECTED] wrote: This brings up an interesting point. Should we allow for form generation based on SQLObject-like classes? This would be my preference. I like the object/declarative way that SQLObject and FormEncode schemas work, because it seems more

[TurboGears] Re: Making form handling and widgets work

2005-12-16 Thread Michele Cella
Dan Jacob wrote: 1. An error_handler argument to @turbogears.expose. This would simplify code like this: ... @turbogears.expose(html=templates.form) def add(self): return dict(form=article_form()) @turbogears.expose(inputform=article_form(), error_handler=add) # go straight

[TurboGears] Re: Making form handling and widgets work

2005-12-16 Thread Kevin Dangoor
On 12/16/05, Wavy Davy [EMAIL PROTECTED] wrote: On 16/12/05, Jared Kuolt [EMAIL PROTECTED] wrote: This brings up an interesting point. Should we allow for form generation based on SQLObject-like classes? There's a ticket open on this, just waiting for the implementation. BTW, though