Dave,

I think the problem with plugins that depend on other plugins will be 
partly taken care of with symfony-forge and the indexing of the 
dependencies information from the source in svn. Most likely from the 
package.xml if possible.

I prefer that symfony goes with one orm, promotes it as the primary orm 
and nothing else. Hopefully Doctrine will be that ORM in the future, 
until that happens I think some things will suffer.

One thing I have suggested is to create some kind of orm/doctrine shim 
that would allow you to write plugins that work both with Doctrine and 
Propel. A few of my plugins I have written them so this is possible, I 
extracted the orm functionality to sub classes and had one version for 
each orm. I do not really like this at all, and would prefer not to have 
to program for 2 different orm's, it is very difficult.

Maybe the only way to do it properly is to have a 
sfGuardForgotPasswordPlugin and it would require sfGuardPlugin?? Thoughts?

- Jon

Dave Dash wrote:
> 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] 
> <mailto:[EMAIL PROTECTED]>>
> Date: Apr 17, 2007 12:41 PM
> Subject: Re: sfGuard and Forgot Password functionality
> To: Dave Dash <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> Cc: [EMAIL PROTECTED] <mailto:[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 <http://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
-~----------~----~----~----~------~----~------~--~---

Reply via email to