On Fri, Feb 25, 2011 at 4:14 PM, Bernhard Schussek <[email protected]>wrote:
> > 2011/2/25 Jeremy Mikola <[email protected]>: > > > 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. > Doesn't the entire form and its contained fields have to originate from the same factory? If I want to use two very different fields, each of which depends on a different service, I'd have to to create my Factory that encapsulates both of those services. Per Stof's suggestion, as much as I hate the idea of injecting the container anywhere (since it hides dependencies), it sounds like that would be a quick solution. > > 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? > Will I be able to make a field that is configurable? For instance, an ODM choice field would need to know the collection it should allow selection from. Looking at FormFactory and how it constructs fields and calls explicit setter methods (the merged $options array itself is never passed in its entirety), I don't see a way for me to implement a custom option. > > 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'm assuming the renderer itself will be a DIC service (outside the scope of your Form component perhaps, since this is something FrameworkBundle would likely define and set in the form.factory service). > 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. > I like the SoC by splitting up rendering (it's good that you'll have no access to raw form objects and their internals from the templates), and making options correspond to explicit methods. One issue I have is that FormFactory seems to be reinventing the concept of a DI container just for forms. Once constructable fields start having dependencies on various services, FormFactory becomes more like a full-fledged service container. I realize there is a difference between the Form Component* *and its Symfony2 implementation via FrameworkBundle, but the most streamlined solution for managing field dependencies IMO is defining those fields as services and adding them to the form (all do-able within DIC service definitions). -- jeremy mikola -- 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
