2011/2/25 John Wards <[email protected]>: > I think you still need to be able to create a form class, even if its more > work. > > How do I add custom things to my Form? a send method, or a custom > validation method? (a overridden isValid etc)
Of course, you _can_ create your own form class, but for most forms I doubt that it will be necessary. > Looking at the Form.php file it seems that Form no longer calls > configure anywhere? So the only way to create a form is through the > chaining in a FormFactory? > > This feels wrong to me. I might be in sf1 forms mode, but I'm not keen on it. I agree it feels strange at first. But this is the only way that I see for managing forms and their dependencies in a simple fashion. Also you get the benefit that you can unit test the controller without having to create a form, because you can stub out the form factory. > I like the ability to do it the new chaining way in FormFactory, > especially as it fits my formbuilder system I am building, but > creating a form to represent a User registration form or adding a new > Company (etc etc) feels really messy. Why? I have little experience with this approach yet, so I'd like to learn more about its problems. > Also you loose the ability to have a base form class which contains > base fields which you can extend from? (Yes you could do this with a > base chain method but still, messy) You can implement a getBaseForm() method. This should really be the same as a BaseForm class. 2011/2/25 Fabien Potencier <[email protected]>: > It's not a refactoring that fixes some problems, it's a totally different > approach! This is really surprising as nobody, as far as I know, was aware > of this big change. I wasn't aware of it myself. It was an experiment that I started just a week ago. There was no point in announcing something that might not even work. It is a refactoring. I changed the organization of the existing code, but hardly added new functionality and changed existing tests as little as possible. > I only had a quick look, but I don't see how the new Twig management could > be more flexible as the Twig theme only takes one template. That's only a small part of the new rendering, and one that can easily be changed. The flexibility lies in the one-renderer-per-field approach, because you can adapt rendering for each field. With the old approach, we just had a set of global helpers that behaved the same for every field or form. Another benefit of the renderers is that the developer can control exactly which information is available to the designer. The designer doesn't have access to the form, the domain object or anything else except if the developer explicitely wants that. My last argument for renderers is separation of concerns. Before, we had lots of rendering-specific code in the fields themselves, for example getId(), getName(), getPattern(), getVisibleFields(), isHidden() etc. All of these methods are completely irrelevant for field binding. Now this information is explicitely generated by the renderer in a reusable fashion (using renderer plugins). 2011/2/25 Jeremy Mikola <[email protected]>: > It looks like FormContext was removed, so I assumed FormFactory is its > evolution, with added support for fields. Is that a fair assessment? FormContext was a hack to transport information from the DIC to the form. I'm happy to have it removed. > I don't think FormFactory should use Doctrine's EntityManager. I agree. I also don't like that FormFactory depends on so many services that need to be instantiated independent of whether the field that requires them is actually created. I see two solutions: Create one factory per field or pass those dependencies manually when creating a field (which means more work by the end user). > How do you plan to support custom fields that might need specific services > to be injected? You can implement your own factory that can require any services that you like. > I'm not following how you plan to support custom options. The FormFactory > merges incoming options with defaults when you request a new field, and then > only a handful of those options are referenced and given to setter methods > on the fields. I'm not sure I understand you? > Since you're introducing a renderer, does that mean all fields will now have > at least one service dependency? Again I'm not sure I understand you. But yes, each field usually has a renderer set, that has a theme which usually uses some external rendering library. I want to emphasize that I'm new to this approach too. But the power given by DI and SoC tells me that we are going the right road, if we only polish it a little. Bernhard -- 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
