Hi folks, I fab suggested we discuss this on the list, Jon and I were discussing how to include the "forgot my password" functionality as part of the featureset of sfGuardPlugin.
Feel free to chime in with your thoughts specifically toward sfGuardPlugin and the forgot password, but let's also look at the larger issues of decoupling functionality and extending functionality... (is their a design pattern master in the house ;) ) How do we extend plugins beyond their solitary uses? I think the issue that I've run into with sfGuard being extended is really trivial compared to some of the issues we'll see with symfony as we go forward. A future issue that we'll be running into is decoupling the ORM from various plugins (specifically sfGuardPlugin, but I imagine others will go through this as well). Yet through all of this we need to keep in mind the "ease of use" factor that Jon mentions below, that these plugins should be ready to go out of the box (or at least with minimal configuration). For the task at hand I am in favor of plugins that depend on other plugins for the meantime, I just hope that doesn't get to become too unwieldy ;) -d ---------- Forwarded message ---------- From: Fabien POTENCIER <[EMAIL PROTECTED]> Date: Apr 17, 2007 12:41 PM Subject: Re: sfGuard and Forgot Password functionality To: Dave Dash <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Hi Dave, You're right. My idea when writing the sfGuardPlugin was to keep it very simple to be pluggable and broad. So, I'd rather prefer not to add the email address to the "required" fields managed by the plugin. The forgotten password feature is quite nice BUT I think Jon implementation is just one way of doing it. So, people will ask for changes to support their own vision of this feature. So, I think we have to keep it outside of the plugin. Perhaps we can refactor the code and package it in another plugin... hmmm... A plugin plugin does not sound nice! Perhaps we can discuss the matter on the dev ML? Fabien Dave Dash wrote: > Hey guys, > > I was looking over: > > http://trac.symfony-project.com/trac/changeset/3789 > > and was curious about the direction we're taking the model for the > sf_guard_user model. I feel like we're taking a step backwards by > coupling profile information (email address_ with the guard user table. > This is data that I'd prefer to keep out of sfGuard. > > I do think however, that the functionality that jwage added is > necessary, but I think we can do that by using the sf_guard_user_profile > table (and configuring that to an extend using the app.yml). > > Jon, since this was your commit, if you're okay with it, I'd like to > revert the schema and I'll volunteer to impliment a "forgotten password" > function that is decoupled. > > Let me know asap, I actually do have a number of apps that use this > plugin, so a model change would either force me to cut this plugin at a > certain revision (which I'd rather not do). > > -d -- Dave Dash 612.670.0621 Discover your favorite restaurant: reviewsby.us gtalk: dave.dash --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
