On 1/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Ah, I see. Thank you for the explanation.
>
> As I said, I think this is going to cause a lot of trouble, docs or no
> -- it's just so counter-intuitive. I'd suggest at least adding some
> kind of thread-local storage to the base widget, so that the docs can
> give a simple solution ("to set per-request properties in a widget, use
> widget.request [or whatever]").
>
> A greater investment that I think would be worthwhile would be to
> profile the two cases (current, vs instantiate/copy per request) and
> see how expensive the (to me at least) intuitive scenario is. If you or
> other folks are interested, I can take a crack at that next week -- my
> access this week is still pretty lousy. Also, I have the flu. Ah,
> vacation! ;)Bummer. Sad way to spend vacation! I can't imagine that it's super expensive to instiantiate the needed widgets for a given request. It just didn't seem important to do so, to me. Here's why: for something to be meaningful to a request, it needs to end up in the dictionary that goes to the template. It's already possible to pass things in to that dictionary via insert() and render() and the widget itself can use update_dict to modify the dictionary on the way in. I looked at it very much like a type of controller. You give it a baseline set of parameters that don't vary and send in the variable stuff at render time. that said, it *has* tripped people up, so eliminating that trip-up spot is a worthy goal. Kevin > > JP > > -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
