Great, that makes a lot of sense. I think those additions will make it much less likely that a profile class will be needed for most of the common cases. And if it is, developers will have the option of extending the schema instead of using the profile table if they prefer.
On Wed, Dec 16, 2009 at 3:25 PM, Jonathan Wage <[email protected]> wrote: > We will add first_name, last_name and email_address for this. > > - Jon > > On Wed, Dec 16, 2009 at 3:14 PM, Tom Boutell <[email protected]> wrote: >> >> 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. >> >> > > > > -- > Jonathan H. Wage (+1 415 992 5468) > Open Source Software Developer & Evangelist > sensiolabs.com | jwage.com | doctrine-project.org | symfony-project.org > > You should follow me on Twitter: http://www.twitter.com/jwage > > You can contact Jonathan about Doctrine, Symfony and Open-Source or for > training, consulting, application development, or business related questions > at [email protected] > > -- > > 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. > -- 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.
