On 2/6/06, Kevin Dangoor <[EMAIL PROTECTED]> wrote:
>
> 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.
I'll have an opportunity to test the form API in the next two weeks,
so I'll see how it goes. Yes, the structure is very different if you
have widget instances in the form class.
Not sure where you see currying. Currying is like a bound method but
more generalized. The leftmost args are fixed, so you only supply the
rightmost args on each call. My decorator-writing ability sucks but
it's something like:
def curried(func, *bound_args):
def curried_func(*args, **kw):
complete_args = bound_args + args
return func(complete_args, **kw)
return curried_func
@curried('arg1', 'arg2')
def my_func(arg1, arg2, arg3, arg4):
return "my_func was called with", `(arg1, arg2, arg3, arg4)`
print my_func('arg3', 'arg4')
--
Mike Orr <[EMAIL PROTECTED]>
([EMAIL PROTECTED] address is semi-reliable)
