Some feedback:
- It looks like FormContext was removed, so I assumed FormFactory is its
evolution, with added support for fields. Is that a fair assessment?
- I don't think FormFactory should use Doctrine's EntityManager. I guess
this slipped in since the entire thing is in-progress, but long-term I think
you would have a FrameworkBundle FormFactory class that integrates with the
DI container, and in turn you might have a FormFactory implementation within
each of DoctrineBundle and DoctrineMongoDBBundle that ensures the respective
managers are available.
- How do you plan to support custom fields that might need specific
services to be injected? Do those services really need to be in the
FormFactory first, or do you imagine we'd inject them through options on the
field. It would be helpful if we had an example of this. Perhaps this
could bypass the need for either ORM/ODM manager existing in any
FormFactory.
- 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 rather indifferent about rendering, as I haven't ran into
roadblocks with the current implementation, but I do like {{ form.rest }}.
One of the biggest, recurring development problems with both Symfony1/2
forms for me has been forgetting to output a field in my template, having
the form invalidate because of that field, and never seeing the error :)
Since you're introducing a renderer, does that mean all fields will now have
at least one service dependency? I'm just thinking of how you were able to
integrate DI in the Validator component - simple validators are still
possible and if the Constraint needed a DI-enabled validator, there was
support for that as well. Just contrasting that with this Form component
remix, as DI is now the only option.
In your code examples, I think creating a HelloFormFactory class is an
alternative to defining the entire form in your DI config. In XML, I'd
probably create my form service as factory-derived from the form.factory
service itself and configure everything using <call> blocks within the
definition. This would be beneficial if particular fields needed DIC params
or other services as their options. Using prototype scope, the DI container
will now effectively become my form factory and I could inject this form
into various controllers, and just call ->setData() once I'm in the
controller action.
On Thu, Feb 24, 2011 at 7:13 PM, Bernhard Schussek <[email protected]>wrote:
> Hi dear Symfony2 devs,
>
> I was pushed by several people to refactor the Form component to be
> more decoupled and make better use of DI. Although I wasn't really
> convinced of this approach at first, I decided to give it a try - and
> am pretty satisfied with the results. Most of the features have been
> refactored, but there are still details that need to be worked on. You
> can find the current progress here:
>
> https://github.com/bschussek/symfony/tree/experimental
>
>
--
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
