On 2/5/06, Mike Orr <[EMAIL PROTECTED]> wrote:
> I don't understand the threading issues so I'm staying out of that.
> Reusing a widget instance has just never been an issue in Quixote. A
> widget instance is specific to a particular widget on the screen in
> one transaction. If two identical forms are on the page, they'd use
> different form instances with different widget instances. It's not
> smart enough to choose the correct form from the input, but you can do
> that manually by examining a hidden field or submit value and then
> telling the code which form object to use. Quixote is multiprocess
> rather than multithreaded so threading issues don't come up. But I
> still don't see why you'd want to share a widget instance between
> threads, which would imply it's being used on multiple forms, and thus
> must be thread safe. In Cheetah we purposely made Template instances
> not threadsafe because it's much more convenient to store state in the
> instance. And the overhead of instantiating extra instances is so
> small it doesn't matter.
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). There are
various ways that the widgets could potentially be instantiated that
don't have threadsafety issues, but they were less pleasant to work
with. The revised widget API makes it more natural to write a widget
in a threadsafe manner (in addition to raising an exception if the
user attempts use that is not threadsafe), so I think we end up with a
pleasing API and no real threadsafety worries.
Saving state in a controller isn't threadsafe, either, but i think
that is a less-natural thing for people to try to do.
Kevin
