Don Hopkins wrote: > The problem with the class based approach is that there's no way to > reconstruct the order of the fields in the class, which is required for > generating forms (of more than one field ;-). Since the fields are > defined in the class's dictionary, which is unordered, there's no way to > determine the order they appear in the source code, so you have to use > an array of fields instead. > > Maybe you could hack around it by using a @decorator that recorded the > order it was applied to methods in another class variable. Oh, but those > are fields not methods. You can't apply decorators to fields, but you > could still call a function for every field that remembered its order. > Eww, that's gross, never mind... > > To me, the order in the class doesn't matter. What usually matter is when it is passed to the "view" in MVC which in TurboGear's case is a dict for Kid to consume. I just created a "preferred ordered dict" which has an optional "field sequence" list member.
So for my CRUD requirement, I just use py:for in Kid and still control the order of how those fields appears. And if I later decide to customize the layout in Kid, the same dict can still be used for direct name access.
