[Patch] Change logic to add avocode twig form resources

[sescandell]

Add twig form resources at the beginning of available resources (so application can override default renders provided by avocode formextensions bundle).

[ioleo]

@sescandell These files must also be loaded after Admingenerator form resources:

• form_div_layout.html.twig
• Admingenerator/GeneratorBundle/Resources/views/Form/fields.html.twig
• avocode/form-extensions-bundle resources
• all the rest

[sescandell]

@loostro

I don't think to test for specific Admingenerator resource name is a good idea. Because of two things:

• first, because it introduces a "hidden" dependency with the AdmingeneratorGeneratorBundle (why should we care about AdmingeneratorGeneratorBundle and not Mopa for example?)
• I checked (maybe too much quickly?) both resources, and the only common block I found is form_row one... but it seems they are the same. So, why did you say that AvocodeFormExtension resources must be loaded before Admingenerator ones?

So, to be "independent" about Admingenerator and any other Bundle, I simply added the same logic I introduced in the Admingenerator:

• we can now deactivate auto resource injection
• if AvocodeFormExtensionsBundle:Form:form_widgets.html.twig is already in twig resources, no resource will be auto injected
• in other cases, AvocodeFormExtensions are prepended

So finally, it permits the developper to import them as he wants depending on its project and its context (by the way, because, I think, CompilerPass order execution is depending on how they are defined in AppKernel, I'm not sure I can force AvocodeFormExtensions resources to be added before Admingenerator ones)

Sounds better for you?

[ioleo]

If Admingenerators form_row block overwrites FormExtensions form_row then the help block will not be rendered and thus HelpMessageExtension will not work. Thats why our resource should be loaded after Admingenerator.

Why do we/I care about Admingenerator? Becouse the basic idea behind this bundle was to provide form types for Admingenerator project. Ofcourse, we may work to make it independent, but I think our first goal should be to make it as easy to use (with Admingenerator) as possible.

[sescandell]

If Admingenerators form_row block overwrites FormExtensions form_row then the help block will not be rendered and thus HelpMessageExtension will not work. Thats why our resource should be loaded after Admingenerator.

Oh yes, sorry, I didn't see this minor change,

Why do we/I care about Admingenerator? Becouse the basic idea behind this bundle was to provide form types for Admingenerator project. Ofcourse, we may work to make it independent, but I think our first goal should be to make it as easy to use (with Admingenerator) as possible.

Ok I see your point. But, as I said, I think we can't guarantee execution order of CompilerPass (I almost sure it is dependent on AppKernel declaration order). I can't be sure that Avocode FormCompiler will be executed after the admingenerator one. So, IMO, current solution is the more flexible:

• by default, we add our theme in first position
• if it is not the user expected behavior, he can define its own order (via its config.yml file), and AvocodeFormExtensions will not change anything

If you don't think this is enough... I'll add a check on Admingenerator includes (but I'm not sure we can guarantee Avocode ones will be inserted after... maybe except if we precise that this bundle must be declared after Admingenerator in AppKernel... but that's not really a perfect solution IMO)

Just let me now,

[sescandell]

@loostro ,

If you don't mind, I would like to merge this PR (I need this flexibility for my project).

Could we so first merge as it, and then discuss on if we really need to check for Admingenerator inclusion (and handle order etc.)?

[ioleo]

@sescandell You can merge anything and anytime without asking me. If I (or anyone) have problems with something we'll just open an issue and discuss it :)