On 2/5/06, Kevin Dangoor <[EMAIL PROTECTED]> wrote: > From the standpoint of widget authoring, just dropping widget into the > namespace is appealing: it's the least amount of work possible. > However, from the standpoint of widget *users*, there is an advantage > to explicitly listing out the variables from the widget that should be > available: *all* variables that the widget uses and defines in the > constructor can also be overridden at display() time. For > consistency's sake, it's nice to think that people wouldn't have to > play a guessing game about whether they can override something.
This is how I know TurboGears is in good hands. The widget author only has to write the code once. The widget user has to use the API again and again in every site. The more concise the better, provided it doesn't get cryptic. 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. -- Mike Orr <[EMAIL PROTECTED]> ([EMAIL PROTECTED] address is semi-reliable)
