On 26/04/2006, at 11:45, Michele Cella wrote:
> > Hi guys, > > Since we are going to have params_doc and update_params, shouldn't > member_widgets work in this way? > > Now: > > class Form(...): > member_widgets = ["fields", "hidden_fields"] > > Right semantic IMHO: > > class Form(...): > params = ["submit_text", "action", "method", ..., "fields", > "hidden_fields"] > member_widgets = ["fields", "hidden_fields"] > > Rationale: > > *All* parameters are listed at params, they are passed at > update_params > and they are documented with params_doct. > If we don't put member_widgets in params we will need another > attribute > to document them and also a incoherency with update_params since he > also gets attribute listed at member_widgets is somewhat harder to > explain in this way. > > In the second way you list *all* your parameters at params, in > member_widgets you list those params that hold references to other > widgets, they are used by retrieve_javascript/ccs and the schema > generation, params classified as member_widgets are also different > since you can't update them at display time. 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 ;) Alberto --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
