Defaults for dicts?

[Kevin Dangoor]

Is this ticket still relevant after all of the latest widget changes?

http://trac.turbogears.org/turbogears/ticket/605

Kevin

--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

[Michele Cella]

Mmm, actually I'm not so sure we should support something like this, it
wouldn't be a standard python behavior I guess...

How is this related to Simon fail-safe mechanism?

Ciao
Michele

[Simon Belak]

Michele Cella wrote:
> Mmm, actually I'm not so sure we should support something like this, it
> wouldn't be a standard python behavior I guess...
>
> How is this related to Simon fail-safe mechanism?

I suppose it is an option, but it doesn't solve much, as we still need
to provide some default approach for dealing with defaults. Having said
that, I wouldn't mind one single bit to flesh it out some more and
decouple it from error handling.

Cheers,
Simon

[Kevin Dangoor]

I actually feel like I'm missing some context when I read that ticket.
I'm not sure which defaults we're talking about and in what context
it's really an issue.

Kevin

[Simon Belak]

Defaults for method parameters. More specifically, defaults for inputs.
Currently it's well-nigh impossible to have meaningful defaults for
nested forms.

Cheers,
Simon

[Michele Cella]

Simon Belak wrote:
>
> Defaults for method parameters. More specifically, defaults for inputs.
> Currently it's well-nigh impossible to have meaningful defaults for
> nested forms.
>

If we want that I think we (well, you :P) can easily do that using
util.recursive_update and updating the method default dict by using the
input values one, that's all it takes, as I said on the ticket we don't
need the different notation, yep nested dict are a bit more painful but
that's what python gives us and we are not using that notation even for
value and options in widgets and I don't think we should provide 2 ways
of doing it, in the controller side I'm more positive about exposing
only regular python. ;-)

Thanks!

Ciao
Michele

[Simon Belak]

I agree, we should reuse update_dict, however I still think it needs to
be a part of every TG instance, not just my super-duper-hot-rod-custom. ;)

Cheers,
Simon

[Michele Cella]

Simon Belak wrote:
> I agree, we should reuse update_dict, however I still think it needs to
> be a part of every TG instance, not just my super-duper-hot-rod-custom. ;)
>

Mmm, I expressed myself in the wrong way!! :D

What I was intending is that you as the "controllers.py/decorator guru"
can do that (in TG not your hot-rod version :D) by using
recursive_update and updating the method default dict (if present) with
the one coming from input_values, that's all it takes.

If you do that please do you think is also worth supporting the same
case for lists (now that we have repeating widgets)? you should update
every element of the default list (if present) that's a dict by
updating it with the same method.

Sorry for the confusion!! :D

Ciao
Michele