On 2/6/06, Mike Orr <[EMAIL PROTECTED]> wrote:
>
> On 2/6/06, Kevin Dangoor <[EMAIL PROTECTED]> wrote:
> > It ultimately wasn't an overhead issue. It was more to do with how the
> > widgets are used.
> >
> > @turbogears.expose()
> > def foo(self):
> > return dict(someform = myform)
> >
> > @turbogears.expose()
> > @turbogears.validate(form=myform)
> > def save(self, blah, blah2, blah3):
> > pass
> >
> > That same form instance is used at class initialization time in two
> > different methods (at least in this style of forms usage).
>
> OK, the difference is that in Quixote the form is instantiated inside
> the method. I use a factory function for each form.
>
> What if you passed the form class or a factory function instead of the
> instance? Then each thread would have its own instance even though
> it's a decorator wrapper, right? What would be lost in terms of TG
> programming elegance?
My example was probably not full enough. The form itself is not the
problem... the problem was more to do with the widgets on the form:
class Foo(WidgetDeclaration):
name = TextField(size=10)
age = TextField(validator=Int())
myform = TableForm(widgets=Foo)
The need for a factory function extends to the widgets themselves.
What *could* be done here is to change from using a widget constructor
directly to currying (I think that's the term I want) the constructor
call and actually doing the instantiation at request time. That may
have been a bit less clear when we were also struggling with the
declarative format for widgets on a form.
It's likely possible to keep the widget user API the same or very
similar, but I'm not sure if there are truly benefits for the widget
creator. Setting whatever you need access to in update_data is easy,
and the safeguard is there for threadsafety.
Kevin
--
Kevin Dangoor
Author of the Zesty News RSS newsreader
email: [EMAIL PROTECTED]
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
