Kevin Dangoor wrote: > On 4/26/06, Michele Cella <[EMAIL PROTECTED]> wrote: > > IMHO member_widgets should just act as a special classifier for a > > params. > > To me, the entire reason params exists is to denote values that can be > passed at __init__ and updated at display time. If this was not the > point of params, we'd just be putting the params as arguments to > __init__. > > member_widgets are listed as they are because they need some special > treatment. They aren't in params, because they don't share the same > trait that is the entire reason params exist. > > > "Ok, my widgets has 5 params, 2 of them are special since they hold > > references to member widgets that the Widget class should know about > > for the schema, for css/js and to make them immutable after > > construction hence I'm marking those 2 inside member_widgets." > > No... it's actually saying, my __init__ has 5 arguments, 2 of which > have member widgets and 3 of which need to be overrideable at display > time. >
Ok, this makes also sense let's keep things simple. ;-) Sorry for the (yet another one...) crazy idea, my mind is pretty vulcanic. :D Ciao Michele PS Kevin if you can take a look at the InputWidget patch and tell me what you think it would be great so after lunch (that means within 1 hour) I can commit it since I really need to do other (no TG) things today. I'm particulary interested in the best way to provide an update_data that acts perfecly like update_params but with a different name, is my solution good? update_data = update_params --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~----------~----~----~----~------~----~------~--~---
