On Wed, Dec 16, 2009 at 2:28 PM, Jonathan Wage <[email protected]> wrote:
> This is not something that is a part of sfDoctrineGuardPlugin so I am not > sure what you mean. We won't be ditching anything because nothing related to > Profiles exists in sfDoctrineGuardPlugin. Sorry, I should have clarified where I was going with that. My impression was that you were going to implement "forgot your password." That would require an email address, ideally an email address of record verified by the user at account creation time so that accounts would be hard to casually steal later. The email address needs to live somewhere, so that brings up the question of whether the new "forgot your password" support would (1) extend the sfGuardUser table with an email address and perhaps a full name (to help get past spam filters), or (2) require that developers put those fields in that profile table, or (3) defer the whole question by requiring devs to implement a hook of some sort to store it themselves. Maybe I'm misinterpreting how you plan to deal with the forgotten-password issue. > No, I think using relationships to add new information to sfGuardUser is > still the right way to go about it at this point. What are the advantages of that approach as you see it? It always seemed like something that was done out of necessity because earlier ORMs didn't have an alternative. A one-to-one relationship where everybody always has one of each strongly suggests just one table to me. But I'm also interested in hearing about situations where it doesn't work out so well. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- You received this message because you are subscribed to the Google Groups "symfony developers" 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/symfony-devs?hl=en.
