Also, I used a method like this:
def dictcombine(dicts):
'''Takes a list of dict objects and combines them'''
return dict([item for d in dicts for item in d.iteritems()])
combined with my msave handler in the controller
def msave(contact, account, extended, **pdata):
tmember = dictcombine([contact, account, extended, pdata])
m = Member(**tmember)
This let me easily combined the different fieldsets in to 1 easy to
use dict for my SQLObject instance. If I can get my current test
working, I'll paste full code of how I am populating the form for
editing as well as saving the new/changed members. To get feedback on
how bad it is, hehe.
Wayne
On Mar 16, 8:20 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Basically we are doing the same thing with a few differences. Mainly I
> instantiate the form before sending it to my template, not sure if
> this is bad practice or not.
>
> As for the form being populated, yes, without the field sets or with
> all the field sets having the same name, I can pass in a member
> instance and it does all the magic for me. My member model and form
> have matching names for their fields. Since the member instance
> supports lookup with keys, when I pass my member instance to my form,
> it automatically populates the data assuming I am not using field sets
> or if I am, as long as I supply the proper key for the field sets in
> the value dict. This goes the same for when I am posting a new member
> via the form. I do my validation for email, userExists, matching
> password, etc.. then I can take the form data and create a new
> instance of member directly from it. But I think your __get_contact/
> account methods might be the trick I am looking for.
>
> This is the example of how I did it when the field sets all had the
> name set to 'fs':http://paste.turbogears.org/paste/1127
>
> Basically looking for a clean and simple way to pass my data in to my
> forms, but I am gonna try adding some helper methods to the Member
> model class to see if that helps for the display part. Those seem like
> what I am looking for. Since that should let do the proper lookup when
> it trys to access member.contact['fname'].
>
> Also, once I stopped using the same name for my field sets, I was able
> to get the Calendar validation to work with the small quirk that it
> was filling in the tg_error for every field in the fieldset.
>
> Wayne
>
> On Mar 16, 1:41 am, "Ian Wilson" <[EMAIL PROTECTED]> wrote:
>
> > Okay well the date validation seems to be working for me so double
> > check your setup.
>
> > I have something like
> > this(widgets/validation):http://paste.turbogears.org/paste/1124
>
> > I still don't quite understand what you are saying about passing a
> > member into the form? Does that usually work... like it pulls the
> > data straight from the sqlobject ? Like member.fname goes into the
> > field fname automatically? If so you could try adding magic
> > attributes to the sqlobject that pull the internal fields into a
> > dictionary or something... or into a struct type class so you could
> > achieve the funcionality of: member.contact.fname. Something to this
> > effect.
> > class Member(SQLObject):
> > ...
> > def _get_account(self):
> > return self
> > def _get_contact(self):
> > return self
>
> > For the most part I just bite the bullet and pass the data in at
> > display time... although it would be nice to have something fancier...
> > it seems like at some point you have to bridge the gap between how you
> > store the data and how you display the data.. and i do that in the
> > controller.
>
> > Like this(controller):http://paste.turbogears.org/paste/1126
>
> > and this(view):http://paste.turbogears.org/paste/1125
>
> > If I shouldn't be flooding the paste server with my notes someone tell me.
> > And also tell this guy:http://paste.turbogears.org/paste/1069
>
> > Anyways I kind of got carried away with the example but tell me more
> > about how you pass in the form values.
>
> > -Ian
>
> > On 3/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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?hl=en
-~----------~----~----~----~------~----~------~--~---
