On Fri, 11 Mar 2011 01:13:01 +0100, Bernhard Schussek
<[email protected]>
wrote:
> 2011/3/11 Benjamin Eberlei <[email protected]>:
>> Ah ok, one config per field type explains the need for FieldPlugins.
>> This brought me to look at config loaders. I don't think they are
>> necessary at all. You should just define a service container tag
>> "form.config" and have all of them injected into a FormFactory and
>> defined as private services.
>
> The config loaders are necessary to use the component without the DIC
> or different DIC implementations.
This doesnt make sense. Any DIC implementation is there to solve the
dependency issue that your loaders create. For usage without a DIC that is
why suggested having two form factories, one for usage without a DIC, and
one that injects the configs.
>
>> Simpler would therefore be:
>>
>> $builder = new FormBuilder($csrfService, $validatorService);
>> $form = $builder->createForm('contact');
>> $form->setData(new ContactRequest());
>> $form->add('text', 'email');
>> $form->add('textarea', 'message'));
>
> What about
>
> $form = $factory->getInstance('form', 'contact');
> $form->setData(...);
> $form->add(...);
>
> ;)
I don't like having to have config abstract classes just to define a form.
Just a personal preference.
>
> Btw, it will be possible to use simple configs without registering
> them in the DIC by passing their FQN:
>
> $form = $factory->getInstance('Acme\BlogBundle\Form\PostFormConfig',
> 'post');
>
>>> The func_get_args code will be removed by changing the signatureof
>>> add() to
>>>
>>> function add($property, $field = null, array $options = array())
>>
>> How would that work? Isnt property a required input for field
>> constructor also?
>
> Yes. Internally, either $factory->getInstance($field, $property) or
> $factory->getInstanceForProperty($this->dataClass, $property) is
> called (depending on whether $field is given or not)
>
>>> Lazy loading here is a good idea.
>>
>> If by lazy loading i get rid of them being used in all but the few
>> fields that need events its ok.
>
> Actually, we could create an own extension of EventDispatcher that
> allows attaching events to objects. Then we could use this single
> shared event dispatcher for all fields.
>
>> Why does it sound like magic to you? Its completely obvious to me.
>>
>> Say you have $templating->render("..", array("form" => $form)); and "{{
>> form_errors(form) }}".
>
> This helper will not exist in the future. I suggest you check my
> slides to learn about the new and improved templating syntax:
> http://www.slideshare.net/bschussek/leveraging-symfony2-forms
>
> Then you'll also make sense of ThemeInterface.
You gave no argument why this helper won't exist anymore. I find the new
form rendering syntax less expressive and it seems it doesn't work in PHP
Templates (without having to use Twig also).
>
> 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
