1: Changing the value of a field after a bind. Almost impossible. Please, add a setValue to the Form class.
2: Extensibility. Extending sfFormField, for instance, is almost impossible because the name of the class is hard coded on sfForm and sfFormWidgetSchema. For me the main concept is: give the developer more freedom and less restrictions. Look at what you have to do to invalidate a subform: http://www.symfony-project.org/more-with-symfony/1_4/en/06-Advanced-Forms#chapter_06_sub_creating_a_custom_validator In the context of a big company, missing features aren't as important as an extensible and decoupled architecture. We need a solid, yet flexible base to build upon. Regards, Valentino On Sep 22, 2:26 pm, Phil Moorhouse <[email protected]> wrote: > Hi - I noticed there's been a fair bit of discussion on the form > framework for Symfony2, and I was wondering if whoever does eventually > take over development was planning on requesting feedback from the > community on what they felt the issues / stumbling blocks / missing > features of the framework were in symfony 1.x? > > I think it would be a good idea to at least talk about use-cases where > "average" symfony users (in which I include myself) have been > struggling so that we can look at avoiding them for Symfony2. > > From following IRC, I'd say two of the most common problems are: > > 1. A readonly widget (for displaying non-editable values) > > 2. Embedded forms with dynamic "add new" and "remove" which don't > require loads of manual boiler plate code to get working. > > I'm sure there are others as well. > > Cheers, Phil -- 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 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
