The current FormBuilder implementation uses the doctrine metadata to generate the correct field. I don't know what you mean by 'dynamic' but the form construction will always required explicit field definition as we don't want new fields to appear once a schema get updated.
The only difference between the current form and the experimental form, is that the later define fields in the DIC. So dependencies can be injected ... On 9 mars 2011, at 17:27, Jesse Greathosuse wrote: > Thomas, > > Thanks for the info. When the new forms paradigm gets fully > implemented will the crud forms be composed dynamically from the ORM > metadata or will they still be built by classes as they are now? > > thanks, > Jesse Greathouse > > On Mar 9, 5:06 am, Thomas Rabaix <[email protected]> wrote: >> On 8 mars 2011, at 17:44, Lukas Kahwe Smith wrote: >> >> >> >>> On 08.03.2011, at 17:41, Lukas Kahwe Smith wrote: >> >>>> Hi Thomas, >> >>>> First up thanks for the AdminBundle [1] >>>> I want to start working on making the Bundle work for ODM's. >> >> Good news ;) however you should not start now! The most important part is >> how Forms are constructed. As Bernhard is working on a new implementation, >> some work will be required on the AdminBundle. >> >> >> >>>> While reviewing the code I noticed that there is a lot of code in the >>>> Controllers that we could maybe move to helpers. This is imho especially >>>> important as right now there is a lot of "format" specific code, that >>>> people might want to handle differently. For example I would like to use >>>> the ViewBundle [2]. Others might want to intentionally not support json or >>>> might prefer to use twig templates for json etc. >> >> Yes for now the CrudController is "html" centric. Recently I move the >> configuration into the DIC so you can use any kind of controller you want. >> So you are free to do anything you want. Extending the CrudController is not >> mandatory (but this code in the configure method is ... ). [1] >> >> >> >>>> So I think in general its a good idea to make the Controllers as slim as >>>> possible, by moving as form logic to the form classes, maybe adding a few >>>> helper services etc. Do you agree? This way its easier to get an overview >>>> when inheriting or its more realistic to re-implement Controllers from >>>> scratch. >> >> Can you give more details about this ? >> >> The form configuration is set by the admin class with the properties or with >> the configureFieldForm method. The CRUDController retrieves the form from >> the admin class. The form creation is done by the FormBuilder service as set >> here [2]. You can create your own ODM FormBuilder. >> >> However the current experimental Form Framework will duplicate this work, >> once Bernhard's work will be merged into the trunk. The form builder will >> change a lot. The current methods will become services, and the form builder >> will be a glue between specific codes required by the AdminBundle and the >> Form field services. >> >> [1]https://github.com/sonata-project/NewsBundle/blob/master/Resources/co... >> [2]https://github.com/sonata-project/AdminBundle/blob/master/DependencyI... > > -- > 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 -- 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
