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 ;)
First I want to apologize for a reply which could be understood a bit negative - but it is only meant as enhancement suggestion: This is indeed an important thing and I hope that there will be some enhancements in the future as the current plugin philosophy is not that good. It is ok for single projects but not enough to manage a real good repository, e.g. an internal company library or symfony-forge or similar. I am a kind of an architecture junky and these are my suggestion: We should add a category level to the plugin system. (what a surprise..) Categories must be selected carefully. (I also think that it is not that good idea to let all people use "sf" as prefix.. sf plugins should be "good quality" and well thought.. ok.. probably not possible..) Second and more important thing is: You all like to speak about rapid application developement in context of Symfony. But the current plugin philosophy does NOT support, respectively represent that! What I mean is the bad modularization, the missing encapsulation into tiers (database/model, view/templates, application logic...). The example we are talking about is a very good one: We now have sfGuardPlugin (using Propel) and sfGuardDoctrinePlugin (using Doctrine). One of the Symfony philosophies is DRY, isn't it? And now think about it in plugin context. It is not used there! But why? These plugins use ugly code repetition (actions and templates), something I don't like - and I know you too. Why don't we really apply DRY to the plugins? I don't understand it.. As an architecture junky I would like to see this separation of the "guard plugin family" - but it also applies to any other plugin: - one plugin that contains the application logic and an interface definition for the database storage - one plugin that contains the templates as people could need to use another layout (this is where I could add another talk about the template/view system that also needs some enhancements, but I don't want to blame too much... ;-) ) or another idea would be to put default templates into the "main plugin" above and give people the possibility to change the template source of the plugin!? - then we need the database access plugins (drivers), one for each ORM / DBAL / whatever.. My opinion is: This separation is obviously and should be obligatory. Unfortunately I have not the time to work on framework stuff - otherwise I had already proposed some code for managing this by providing some base classes using the appropriate design patterns. Regards, Matthias --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
