Symfony 2.8 & 3.0 compatibility

[sescandell]

Ready to review

Developments:

• Form references as FQCN
• Embed types
• Tests

BC Break

Initialization

The bundle initialization in you AppKernel file now need the kernel object as a parameter of the constructor.

Embed types

embed_types in generators is now not anymore necessary. Use the FQCN form name of your generated forms, and everything will be fine!

[sescandell]

Note : one deprecated notice comes from knp-menu and is depending on commit KnpLabs/KnpMenu@18253a4

No tag exists today

[bobvandevijver]

@sescandell I changed some indentations in the list to keep them readable :)

[sescandell]

@bobvandevijver 👍

From @sescandell
Note : one deprecated notice comes from knp-menu and is depending on commit KnpLabs/KnpMenu@18253a4

No tag exists today

I found a way to fix that on our side, I'll hand it in next commit

[sescandell]

ping @loostro , @tobias-93 , @bobvandevijver

[sescandell]

Demo bundle is sync with that branch

[tobias-93]

@sescandell we have something like:

params:
  fields:
    mentors:
      formType: Admingenerator\FormExtensionsBundle\Form\Type\DoubleListEntityType
      addFormOptions:
        query_builder: function ($er) { return $er->createQueryBuilder("m")->join("m.person", "p")->orderBy("p.fullname"); }
        multiple: true

[ioleo]

@sescandell yes, the use case (problem) embed types were solveing was when Generator A wanted to use a form generated by Generator B (eg. as nested form). Thus, if empty cache, it required to first generate Generator B (only the form types). If it is handled now automatically - then thats a very nice improvement.

[tobias-93]

Ok my example is a bit lame (it can be solved using a sortOn), but you get the thing I want to do I hope?

[sescandell]

@tobias-93 OK, I'll set convert_as_form back...

@loostro I'll push a sample in the demo project so we can be sure it is working well

[sescandell]

Except for query_builder does anyone use convert_as_form capacities?

@loostro @bobvandevijver @tobias-93 do you mind if I set as "deprecated" the convert_as_form function?
I personnaly never use this option. For these cases, I prefer to use 'getMyPropertyOptions() method than writing PHP in YML files.

[calvera]

@sescandell

i'm not sure if it is convert_as_form use:

        _start_range:
            label: Date Range
            filterable: true
            filterType: s2a_daterange_picker
            dbType: date
            formOptions:
                opens: left
                parentEl: div.modal
                ranges:
                    'Next 7 Days': "[moment(), moment().add(6, 'days')]"
                    'Tomorrow': "[moment().add(1, 'days'), moment().add(1, 'days')]"
                    'Today': "[moment(), moment()]"
                    'Yesterday': "[moment().subtract(1, 'days'), moment().subtract(1, 'days')]"
                    'Last 7 Days': "[moment().subtract(6, 'days'), moment()]"
                    'Last 30 Days': "[moment().subtract(29, 'days'), moment()]"
                    'This Month': "[moment().startOf('month'), moment().endOf('month')]"
                    'Last Month': "[moment().subtract(1, 'month').startOf('month'), moment().subtract(1, 'month').endOf('month')]"

[sescandell]

@calvera after PHP inside YML, Javascript! I love to see how other people uses the bundle, we always found some things we never thought about :)

Actually, it should not be a convert_as_form option. I will check this is still working with this PR.

Thanks for sharing!

[tobias-93]

@sescandell I'm not against deprecating stuff that's either hard to maintain or superseded by better options, but I'm just curious why this needs to be removed.
Furthermore in this case I can see that it can work in another way. My only problem would now be that I would have to adjust it in the New, Filters and EditType. The old behavior enabled us to keep everything the same for all Types (although that is not always needed, I can understand).
But I can live with it either way. Could you describe it in the Upgrade documentation?

[sescandell]

@tobias-93

No, thanks to @loostro , in the new generator, an MyModelOptions object can be used to avoid duplications of custom options in New, Edit and Filters form (no sample for now, but available here and here.)

We are all agree documentation need improvements. I know @bobvandevijver is working on it. I'll, on my side, work on the demo project too.

I've made a mistake removing it. I'll revert this modification (updating how it works, and adding tests).

Hopefully, you're all here to check my errors! :)

[tobias-93]

@sescandell thanks!
We'll always be there ;)

[bobvandevijver]

Wauw, I did not know about that MyModelOptions class... Will add it to my todo list!

[sescandell]

I reverted back convert_as_form option. Just made some modifications and added some tests.

Is everything OK for you now?

[tobias-93]

@sescandell could you add it to the form types again? This way it cannot be used yet...

[sescandell]

Ohh, sorry, it seems I partially commited my changes...

I'll push it sunday (not on my personnal computer right now and I'll get it back only Sunday... sorry :/)

[tobias-93]

@sescandell no problem. Next week I'll be on holiday so I'll review on the 1st of February. And I must say I never checked Symfony 3.0 so I cannot say anything about the compatibility with that (can only check 2.8 due to low PHP version :(

[sescandell]

Ready for review (again :) )