I don't think it needs to be a different plugin for each driver for 
sfGuardPlugin, the calls in the actions to the database would be to an 
extracted class, that would call the appropriate methods for 
doctrine/propel depending on how sfGuardPlugin is configured.

I agree we'd then be able to create the following: sfGuardRegisterPlugin 
and sfGuardForgotPasswordPlugin.

- Jon

Matthias Nothhaft wrote:
> Thank you. :-)
>
> Hm.. who else is working on the sfGuard plugin(s) ?  I don't want to
> change things before getting more feedback as sfGuard is a pretty
> important plugin...
>
> What do other people think about:
>
> - Making sfGuard driver based?
>   - one main plugin
>   - driver plugins for Propel & Doctrine
>   - adding further plugins for
>     - reset password
>     - a registration form
>     - other stuff!?
>
> - Problem: admin generator (is not driver based itself)
>
>
> Regards,
> Matthias
>
>
>
> Jonathan H. Wage wrote:
>   
>> 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