Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for editable association fields from type choice in Lis… #4449

Merged
merged 8 commits into from Apr 24, 2017

Conversation

christingruber
Copy link
Contributor

@christingruber christingruber commented Apr 11, 2017

I am targeting this branch, because this is new feature with BC.

Changelog

### Added
- Added editable support for association fields from type choice in `ListMapper`
- Added also new `class` option for field description

To do

  • Update the tests
  • Update the documentation

Subject

Added support for editable association fields from type choice in ListMapper, also added new field description option class. As example:

    protected function configureListFields(ListMapper $listMapper)
    {
        $listMapper
            ->add('status', 'choice', array(
                'editable' => true,
                'class' => 'Vendor\ExampleBundle\Entity\PageStatus',
                'choices' => array(
                    1 => 'Active',
                    2 => 'Inactive',
                    3 => 'Draft',
                ),
            ));
    }

->getAssociationNames();

if (!in_array($field, $associations)) {
return new JsonResponse(array(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not throw an exception instead ? This would be triggered by a programming error, right?


if (!$value) {
return new JsonResponse(array(
'status' => 'KO',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was gonna say "use a status code, duh!", but then I saw that's what is being done in the whole class… anyway, please set the status code to 400.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Statuscode 400 for all KO responses in method setObjectFieldValueAction(), right? Or only for my patched part?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a 404 would be even better in your case.
For other responses it depends, but it's not your responsability (of course if you want to rework that, it will a very welcome change though). Some should use 405, others should use 404, and others should use 400. Then, client-side, the statusCode option of jQuery.ajax should be used instead of relying on this field status which contains… a code.

Copy link
Contributor

@greg0ire greg0ire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, nice job!! Tiny changes needed…

$context = $request->get('context');

$admin = $this->pool->getInstance($code);
$admin->setRequest($request);

// alter should be done by using a post method
if (!$request->isXmlHttpRequest()) {
return new JsonResponse(array('status' => 'KO', 'message' => 'Expected a XmlHttpRequest request header'));
return new JsonResponse('Expected a XmlHttpRequest request header', 405);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"a" => "an" (the sound "ex" starts with a vowel)


if (!$value) {
return new JsonResponse(sprintf('Edit failed, object with id "%s" not found in association "%s".',
$originalValue, $field), 404);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not PSR-compliant, although not detected yet. Please put each sprintf argument on its own line.

@greg0ire
Copy link
Contributor

  • Fix http status handling for json responses on editables

This is pedantic : it fixes no bug, and is not a visible improvement for the user (I think). If you agree, remove it from the changelog.

'status' => 'KO',
'message' => 'The field cannot be edit, editable option must be set to true',
));
return new JsonResponse('The field cannot be edit, editable option must be set to true', 400);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"edit" => "edited"

}

if ($request->getMethod() != 'POST') {
return new JsonResponse('Expected a POST Request', 405);
return new JsonResponse('Expected an POST Request', 405);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Post starts with a consonant sound, so "a"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops!

@greg0ire
Copy link
Contributor

greg0ire commented Apr 13, 2017

Can you add some tests here : https://github.com/sonata-project/SonataAdminBundle/blob/3.x/Tests/Controller/HelperControllerTest.php ? Could be merged anyway if you can't, couldn't it @sonata-project/contributors ?

@greg0ire
Copy link
Contributor

@sonata-project/contributors please review

@greg0ire greg0ire merged commit d8493f1 into sonata-project:3.x Apr 24, 2017
@vworldat
Copy link

vworldat commented May 3, 2017

@sonata-project/contributors how is this BC break compatible with semver? Tagging this as 3.17 broke compability with current SonataPageBundle (enabling/disabling blocks does not work anymore because the javascript in sonata-page.back.js is now outdated).

@greg0ire
Copy link
Contributor

greg0ire commented May 3, 2017

the javascript in sonata-page.back.js is now outdated

Can you elaborate? Where precisely is the BC-break?

@vworldat
Copy link

vworldat commented May 3, 2017

The javascript explicitly checks for the status and OK JSON response that has been removed, e.g. here: https://github.com/sonata-project/SonataPageBundle/blob/3.x/Resources/public/sonata-page.back.js#L589

I don't know if any other libraries depend on those responses. Changing API response syntax is a breaking change to me 🙂

@greg0ire
Copy link
Contributor

greg0ire commented May 3, 2017

how is this BC break compatible with semver

It clearly isn't, I just wasn't aware that was part of a public API. Would you kindly make a PR that would restore the array, but keeps the status code? Also, we should deprecate this key, but I'm can't see how to achieve that with JSON. In the future, the page bundle and all other dependent bundles should rely on standard http status codes instead of custom OK / KO codes

@maarekj
Copy link

maarekj commented Jun 13, 2017

Effectively it was a bc break in my code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants