I like this very much. Francois, how do you feel about taking this plugin one step further and we change the name of this to sfDbFinderPlugin, that we way we can offer this same fluent interface for other ORMs. So, sfPropelFinder would become sfDbFinder, and share any common functionality in them, but I am not sure if they will ever have the need to share things.
class sfDbFinder.. class sfPropelFinder extends sfDbFinder../ class sfDoctrineFinder extends sfDbFinder... Or we can have.. interface sfDbFinder... class sfPropelFinder implements sfDbFinder... class sfDoctrineFinder implements sfDbFinder... I think this is the first step in creating a ORM abstraction layer. As I write this e-mail, I am thinking now maybe we should expand the plugin name out a little more so we can have a common interface for managing records too. This is a first step in doing this "Creating light-weight ORM transparency layer for plugins to have DRY plugins", from the 2006 GSOC wiki page: http://trac.symfony-project.com/wiki/GoogleSummerofCode2008 Feel free to turn down the idea, just thinking out loud here ;) - Jon -- Jonathan Wage http://www.jwage.com http://www.centresource.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
