No, now that I think about it I think you are right it should be bundled with sfGuardPlugin and just be a configurable option for them to use in addition to the base sfGuardPlugin functionality.
As for the auto loading of models, in order for this to be possible I think we may need to have a manual installation step when you choose which ORM you are using. That kind of sucks :( - Jon Francois Zaninotto wrote: > Are the reset password/registration form/other stuff able to work without an > sfGuardPlugin installed? If not, it seems to me that they should be optional > features bundled with the main plugin, that you can activate/deactivate via > configuration (see sfSimpleBlogPlugin for instance). > > As for bundling two versions of the model in the same plugin, a problem > might be the autoloading. Both Propel and Doctrine model classes will be > autoloaded and therefore in conflict... > > François > > -----Message d'origine----- > De : [email protected] [mailto:[EMAIL PROTECTED] > De la part de Matthias Nothhaft > Envoyé : lundi 21 mai 2007 16:55 > À : [email protected] > Objet : [symfony-users] Re: sfGuardDoctrine > > > 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 -~----------~----~----~----~------~----~------~--~---
