On Fri, 11 Mar 2011 09:57:03 +0100, Bernhard Schussek
<[email protected]>
wrote:
> 2011/3/11 Benjamin Eberlei <[email protected]>:
>> 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.
> 
> That's what I did, only that duplicate code is in the factory, while
> separate code is in the loader. I can't see the problem about this.

It introduces yet another layer of interfaces and implementations that is
not necessary, the FormFactory can already do all that. There is an
interface and the required functionality is very limited, no need to wrap
the config stuff in it. Additionally the config loader stuff has dependency
problems as discussed by others, it depends on EntityManager and it makes
it very hard to extend from several external sources.

> 
>> 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).
> 
> How can
> 
> {{ form.errors }}
> 
> be less expressive than
> 
> {{ form_errors(form) }}
> 
> I honestly dont understand.

That is the most simple example. but "form.vars.fields" vs form.fields is
a difference aswell as some others you showed in your slides.

I dont understand why we need this ThemeInterface, when clearly this is
just circumventing what view helpers are for. What is the benefit compared
to view helpers? How would in your case a form work that is renderer in
different template engines? 

> 
> You can use the new syntax without Twig once we have more themes than
> just TwigTheme. PhpTheme will be worked on.
> 
> 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

Reply via email to