Alberto Valverde wrote: > > Mmmm, I don't like this. Isn't it inconsistent to have some "params" > that do not work as the rest of "params" because they are also listed > at "member_widgets"? This could get even more confusing when multiply > inheriting IMO. Keep in mind too that "param_docs" doesn't even exist > yet ;) >
But we will have update_params soon, and params_doct takes 3/4 lines of code in meta.py. No problem for me, but how we document them when we have params_doc? member_widgets_doc? IMHO member_widgets should just act as a special classifier for a params. Anyway personally I can't see how is inconsistent that some params work differently since they are listed in member_widgets, to me is quite the contrary, they aren't suddenly working inconsistently but they are working in this way because you're *explicitly* stating this: "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." The inconsistency lies in the actual behavior, we will have update_params, we describe it in this way: "In update_params you receive a dict with a key associated to every paramater you've listed in params, here you can update this dict before sending it to the widget template." Ok, fine, then we should add. "Oh, if you're using a CompoundWidget you also receive a key for every paramater listed at member_widgets, member_widgets act like params but here you put paramater holding references to other widgets, keep in mind that params listed here are immutable at display time". Instead of just saying: "This is a CompoundWidget, if one or more of your params are holding references to other widgets you need to list them in member_widgets, keep in mind that params listed here are immutable at display time." To recap: Every parameter listed at params can be documented with params_doct, and ends up in the update_params's dict. VS Every parameters listed at params can be documented with params_doct and ends up in the update_params's dict, but if you're using a CompoundWidget every parameter listed in member_widgets also ends up in update_params (oh, why you haven't called it update_params_and_member_widgets then? :D) and contrary to params_doc actually there is no way to document it. D'oh I always endup with loooong emails, sorry guys (and Alberto) but I like to explain why I'm proposing something... :D TO NOTE: no backward incomp, if a widget is only listing it at member_widgets I will issue a Deprecation and say "Ehy, please list these parameters in params also to make things clear.". Ciao Michele PS I can't see the problem with inheritance, there are no changes needed at meta.py. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
