[symfony-users] Re: Important sfDoctrineApplyPlugin news
Hi Tom, Great news! We had a discussion already half a year ago on this topic. Did not have the time to do it myself as I was full of deadline projects. Had a peak in de code, and have a small request: Can you enhance the schema.yml also with a 'middle_name'? In Holland, and maybe other countries, we have these akward names like 'Jan de Jong', where 'de' should not be in the last name, e.g. it should be sorted on 'Jong'. Maybe you can make an app_setting for it. Or I can commit some code for it. Let me know, Thanks, Lambert On Jul 1, 9:28 pm, Tom Boutell t...@punkave.com wrote: The svn trunk of sfDoctrineApplyPlugin will soon contain bleeding edge code. You should NOT pin the svn:externals of your project to the trunk. Instead, you may pin them to the new 1.1 branch, which contains the stable release you're used to. Change your externals to read like so: sfDoctrineApplyPluginhttp://svn.symfony-project.com/plugins/sfDoctrineApplyPlugin/branches... You could also pin them to the new 1.2 branch, but that would require considerable work on your part (read on). I will leave the trunk in its current boring state for one month to give folks a chance to take notice of this change. I have also placed a warning file in the trunk. Development of the 1.2 branch is quite far along, and in fact there's a fully working version in the 1.2 branch now, with the following major changes, many of which are breaking changes unless you do some migration work on your database: * Relies on extension of the sfGuardUser table rather than a profile class for better database normalization * Forms are now empty extensions of Base versions so you can do the usual Symfony thing to override them at the project level (you can also use my app.yml approach) * Forwards and backwards compatible with sfDoctrineGuardPlugin's current stable release and its new trunk version * First name, last name and email address fields now consistent with sfDoctrineGuardPlugin's new trunk * Uses Symfony's built-in SwiftMailer support, removing the Zend Framework requirement FAQs: But I'm already using it and I don't want to make changes! Don't. Keep using the 1.1 branch. Upgrading is pretty tough, in particular because the old version only has a fullname field and you have to migrate fields from profile to sfGuardUser. But sfDoctrineGuardPlugin's new trunk has its own register feature! Yes, but it has no email confirmation of new accounts, so it does not currently meet the needs of most sites that are currently using the apply plugin. Doesn't sfDoctrineGuardPlugin's trunk have its own Forgot Password feature? Yes, and it does do email confirmation. It's pretty much equivalent to the same feature in the apply plugin. Use it if you like it. What is the future of sfDoctrineApplyPlugin? We'll see! If sfDoctrineGuardPlugin incorporates email confirmation for new accounts, it might not be necessary to maintain a separate plugin anymore. Do I have to use the svn trunk of sfDoctrineGuardPlugin? No. sfDoctrineApplyPlugin's 1.2 branch works with both the 1.3 branch (aka the 1.4.x release versions) *and* the trunk of the guard plugin, thanks to schema merging. When will a stable 1.2 release appear? Shouldn't be long, since we need this in a finalized form for our own projects. -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.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
Re: [symfony-users] Re: Important sfDoctrineApplyPlugin news
You can add this in your project's schema.yml, once it's released. :) Cheers, Daniel On 02.07.2010, at 10:34, lambert_b wrote: Hi Tom, Great news! We had a discussion already half a year ago on this topic. Did not have the time to do it myself as I was full of deadline projects. Had a peak in de code, and have a small request: Can you enhance the schema.yml also with a 'middle_name'? In Holland, and maybe other countries, we have these akward names like 'Jan de Jong', where 'de' should not be in the last name, e.g. it should be sorted on 'Jong'. Maybe you can make an app_setting for it. Or I can commit some code for it. Let me know, Thanks, Lambert On Jul 1, 9:28 pm, Tom Boutell t...@punkave.com wrote: The svn trunk of sfDoctrineApplyPlugin will soon contain bleeding edge code. You should NOT pin the svn:externals of your project to the trunk. Instead, you may pin them to the new 1.1 branch, which contains the stable release you're used to. Change your externals to read like so: sfDoctrineApplyPluginhttp://svn.symfony-project.com/plugins/sfDoctrineApplyPlugin/branches... You could also pin them to the new 1.2 branch, but that would require considerable work on your part (read on). I will leave the trunk in its current boring state for one month to give folks a chance to take notice of this change. I have also placed a warning file in the trunk. Development of the 1.2 branch is quite far along, and in fact there's a fully working version in the 1.2 branch now, with the following major changes, many of which are breaking changes unless you do some migration work on your database: * Relies on extension of the sfGuardUser table rather than a profile class for better database normalization * Forms are now empty extensions of Base versions so you can do the usual Symfony thing to override them at the project level (you can also use my app.yml approach) * Forwards and backwards compatible with sfDoctrineGuardPlugin's current stable release and its new trunk version * First name, last name and email address fields now consistent with sfDoctrineGuardPlugin's new trunk * Uses Symfony's built-in SwiftMailer support, removing the Zend Framework requirement FAQs: But I'm already using it and I don't want to make changes! Don't. Keep using the 1.1 branch. Upgrading is pretty tough, in particular because the old version only has a fullname field and you have to migrate fields from profile to sfGuardUser. But sfDoctrineGuardPlugin's new trunk has its own register feature! Yes, but it has no email confirmation of new accounts, so it does not currently meet the needs of most sites that are currently using the apply plugin. Doesn't sfDoctrineGuardPlugin's trunk have its own Forgot Password feature? Yes, and it does do email confirmation. It's pretty much equivalent to the same feature in the apply plugin. Use it if you like it. What is the future of sfDoctrineApplyPlugin? We'll see! If sfDoctrineGuardPlugin incorporates email confirmation for new accounts, it might not be necessary to maintain a separate plugin anymore. Do I have to use the svn trunk of sfDoctrineGuardPlugin? No. sfDoctrineApplyPlugin's 1.2 branch works with both the 1.3 branch (aka the 1.4.x release versions) *and* the trunk of the guard plugin, thanks to schema merging. When will a stable 1.2 release appear? Shouldn't be long, since we need this in a finalized form for our own projects. -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.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 -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.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
[symfony-users] Re: Important sfDoctrineApplyPlugin news
On 1 Lug, 21:28, Tom Boutell t...@punkave.com wrote: * Forms are now empty extensions of Base versions so you can do the usual Symfony thing to override them at the project level (you can also use my app.yml approach) Is there any specific reason for not using the standard prefix Plugin, e.g. PluginFooBarForm? Don't you think that prefix Base could lead to confusion with generated forms? cheers Massimiliano -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.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