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 -~----------~----~----~----~------~----~------~--~---
