I think you are right, the sfGuard plugin should be consolidated in to 
one plugin, and use extracted drivers for the database, so we can have a 
config option to use doctrine or propel, and then the other 
functionality related to auth, should be written as separate plugins but 
sfGuardPlugin should be written to handle the integration/communication 
to the other related plugins.

- Jon

Matthias Nothhaft wrote:
> Jonathan H. Wage wrote:
>   
>> Do you have time to help implement the plugins in this way?
>>
>>     
>
> I need generic user functions for severel projects - so yes, I would
> help - no question. I would like to have flexible / pluggable code, e.g.
> with full I18N support and so on. We only need to find a good solution
> how it should look like at the end.
>
> One problem is the admin generator as it directly depends/uses Propel or
> Doctrine. My opinion is that this is a big disadvantage of the admin
> generator at all.. But we should make some small steps before doing the
> big ones.. ;-)
>
> Regards,
> Matthias
>
>
>
>
>   
>> Matthias Nothhaft wrote:
>>     
>>> Jonathan H. Wage wrote:
>>>   
>>>       
>>>> That is correct, I added the e-mail address because it was needed for 
>>>> the forgot password functionality, then someone came along and didn't 
>>>> like it so they removed the e-mail address, but it looks like they did 
>>>> not remove it completely.
>>>>
>>>> How about we add the e-mail address to the plugin but make it a 
>>>> configurable option in the schema. That way we can have the e-mail 
>>>> address and forgot password functionality as something you can turn on 
>>>> and off?
>>>>
>>>> Or maybe somehow we can create a sfGuardForgotPasswordPlugin and hook it 
>>>> in to sfGuard? Any ideas?
>>>>     
>>>>         
>>> This is a question of how to organize plugins of plugins.
>>>
>>> My wish and hope is: Please do not only "fix this plugin" but think
>>> about a general solution to have a good concept for future plugins.
>>>
>>> A second wish is: Please consider to change the plugins so that the
>>> sfGuardPlugin is driver based:
>>>
>>> One sfGuardPlugin and driver plugins for Propel and Doctrine.
>>>
>>> Then the plugin needs some Mixins or something like an event/observer
>>> support so that other plugins can easily plugin.. (I hate the term
>>> "plugin"...) ;-)
>>>
>>> Hmm..  I hope one day some people will understand why I repeat these
>>> wishes again and again... :-(
>>>
>>> It would make it more fun to contribute and much easier to build a nice
>>> plugin library for symfony.
>>>
>>> Regards,
>>> Matthias
>>>
>>>
>>>
>>>
>>>   
>>>       
>
>
> >
>
>   

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"symfony users" 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-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to