i have developed sfDoctrineGuardExtraPlugin and it have a 1.3 branch that use all the new features extending schema (add email_address) and use the new email system the plugin is also full testet see http://svn.symfony-project.org/plugins/sfDoctrineGuardExtraPlugin/branches/1.3/.
so take a look at it. greetings Gimler On Dec 16, 9:30 pm, Tom Boutell <[email protected]> wrote: > 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.
