> Separation of widgets and validators is too great I don't think Symfony 1.2 is all that boggling to learn - especially if you follow the Jobeet tutorial. But I have to agree with this one. Forms are fine as far as they go. But it's essentially impossible to implement a widget that has any real depth to it because you need multiple controls making up one greater "widget" and you can't manage them intelligently from inside a widget class.
This is why sfWidgetFormInputFileEditable is basically just a stub and you have to add the moving parts yourself. (The answer might be "use an embedded form," but so far I hear a lot of complaining about the embedded form implementation. I haven't started experimenting with it yet myself.) > And, worst of all: why isn't there a single user management plugin with a > simple registration form and an implemented remember me feature? sfGuard is > required in nearly every web app, and yet I can't understand why it's > incomplete. I think it centers around the idea that everyone's needs for fields beyond the username and password will be too different. But I think that's a mistake because it's a rare application that won't need full name and email address fields, and I really doubt anyone would scream bloody murder if their application happened not to need those fields. I humbly suggest that merging my sfDoctrineApplyPlugin into sfDoctrineGuardPlugin would be a Good Thing (tm). If not that, then it should at least be a candidate to be considered a core plugin so that people like yourself find it the first time they look. It implements the "forgot my password" link, it's i18n, it jumps through all the usual hoops to do email validation of new accounts and password changes without introducing security holes (and there are more hoops than you might think). It also takes full advantage of Symfony 1.2 forms to make the rest of your profile class editable as painlessly as possible. A Propel port wouldn't be hard to do, anyone could pick it up and knock that out quickly. If the plugins were merged there would be growing pains- developers wouldn't be thrilled to discover they needed new fields in the sfGuardUser table- but eliminating joins is good for you. And Doctrine's database meta-API could be used to create a Symfony task that adds them for you. No muss, no fuss... also, your own profile class could perhaps be a Doctrine column aggregation subclass of the user class, completely eliminating the "join everywhere all the time" behavior associated with sfGuard users right now. More options would be needed to cover common scenarios, including support for closed sites users can't apply for accounts on, and perhaps support for invitations. But my previous standalone PHP Accountify package had those options, so it wouldn't be hard to bring them over. -- Tom Boutell www.punkave.com www.boutell.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
