With 3 lines of code I have a working solution but this won't go into 0.9a5, I need to flesh out some other things before doing that, for example in your code what name do you expect the widget to get?
my_common_widget will be used name, since the widget at this point is_named we can't change this state arbitrarily. Ciao Michele Michele Cella wrote: > Mmmm, everytime a widget is declared it increments a global counter to > keep the right order of declaration (since a class dict is not ordered > sadly), we may experiment with tweaking the WidgetsList so that when a > new instance of it is created it tells the widget to increment it's > counter this could do the trick, I'm going to experiment with it > quickly since I need to do some Java programming here also... :-( > > Ciao > Michele > > Jorge Godoy wrote: > > Hi... > > > > > > Continuing to refactor several forms I isolated some common fields and I > > found > > out that I can "reuse" them inside a new list. Something like this: > > > > class CommonWidget(widgets.WidgetsList): > > my_common_widget = widgets.SomeField(...) > > > > class UseCommonWidget(widgets.WidgetsList): > > one_widget = widgets.OneField(...) > > another_widget = widgets.AnotherField(...) > > common = CommonWidget()[0] > > > > class UseCommonWidgetAsWell(widgets.WidgetsList): > > other_widget = widgets.OtherField(...) > > yet_another_widget = widgets.YetAnotherField(...) > > common = CommonWidget()[0] > > after_common_widget = widgets.AfterCommonField(...) > > > > > > > > And this works except for the fact that "CommonWidget" doesn't respect the > > ordering while displaying a form that uses any of UseCommonWidget or > > UseCommonWidgetAsWell. They are placed as the first widget while rendering > > the template. It doesn't matter -- on my tests -- what type of widget is > > SomeField (TextField, CheckBox, SingleSelectField) this always happens. > > > > If I have this "CommonWidget" as the last one there's no problem in > > concatenating it while creating the form and in fact I do that for several > > forms. The problem is when "CommonWidget" should be in the middle of the > > form what would require me to split the form in two so that I could > > concatenate them -- breaking the "logic" flow sometimes. Or when there are > > three, four different common fields (it is not feasible to break a form in 5 > > or 6 parts just because of that). > > > > Why am I worried with that? Because it requires one to either duplicate > > code > > and makes maintenance more problematic and also because this is not the > > behavior we have with lists, where order is preserved: > > > > >>> some_list = [1] > > >>> another_list = [2, 3, some_list[0], 4] > > >>> another_list > > [2, 3, 1, 4] > > >>> > > > > So, is there any "magic" going on here? Is it intentional? If not, is it > > possible to fix this so that we have a consistent behavior with lists and > > widgets lists? > > > > (Making it clear, these aren't HiddenFields ;-)) > > > > -- > > Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
