Comment obtenir de l'enfant objet incorporé Admin classe Sonata Admin?

Je vais essayer d'obtenir et manipuler le réel de l'objet lié à une ImageAdmin classe dans SonataAdmin (à l'aide de Symfony 2.3). Cela fonctionne très bien lorsque l'ImageAdmin classe est la seule à être utilisé. Mais quand ImageAdmin est incorporé dans un autre Admin, il va terriblement mal.

Voici ce qui fonctionne lorsque vous n'avez pas intégré les Admins:

class ImageAdmin extends Admin {
    protected $baseRoutePattern = 'image';

    protected function configureFormFields(FormMapper $formMapper) {
        $subject = $this->getSubject();
    }
}

Mais lorsque vous incorporez ImageAdmin dans ParentAdmin en utilisant ceci:

class PageAdmin extends Admin {
    protected function configureFormFields(FormMapper $formMapper) {
        $formMapper->add('image1', 'sonata_type_admin');
    }
}

Puis, lorsque vous êtes de l'édition d'un Parent de l'élément avec l'id 10 et appel getSubject() dans ImageAdmin vous obtenez le Image avec l'id 10!

En d'autres termes getSubject() extraits de l'id de l'URL, puis appelle $this->getModelManager()->find($this->getClass(), $id);, qui renvois le Parent de l'id et l'id de l'Image. Oups!

Donc... ce que je veux faire est d'être en mesure de s'emparer de l'objet réel qui est en cours de rendu/édité dans le courant ImageAdmin exemple, si il est en cours de modification, directement ou par l'intermédiaire d'un formulaire intégré, et ensuite être capable de faire des choses avec elle.

Peut-être getSubject() est le mauvais arbre à aboyer, mais je remarque que $this->getCurrentChild() retourne false lorsqu'il est appelé à partir de ImageAdmin::configureFormFields(), même si les ImageAdmin est incorporé à l'aide de la sonata_type_admin type de champ. Je suis assez confus...

De toute façon, j'espère qu'il est possible de se procurer de l'objet dans certains évident que j'ai négligé et que quelqu'un ici peut aider à m'éclairer!

OriginalL'auteur caponica | 2013-08-07

sonata-admin symfony

Grâce à Tautrimas pour quelques idées, mais j'ai réussi à trouver une réponse à cela:

Dans ImageAdmin mettez ceci:

protected function configureFormFields(FormMapper $formMapper)
{
    if($this->hasParentFieldDescription()) { //this Admin is embedded
        $getter = 'get' . $this->getParentFieldDescription()->getFieldName();
        $parent = $this->getParentFieldDescription()->getAdmin()->getSubject();
        if ($parent) {
          $image = $parent->$getter();
        } else {
          $image = null;
        }
    } else { //this Admin is not embedded
        $image = $this->getSubject();
    }

    //You can then do things with the $image, like show a thumbnail in the help:
    $fileFieldOptions = array('required' => false);
    if ($image && ($webPath = $image->getWebPath())) {
        $fileFieldOptions['help'] = '<img src="'.$webPath.'" class="admin-preview" />';
    }

    $formMapper
        ->add('file', 'file', $fileFieldOptions)
    ;
}

Je vais poster cela dans la prochaine SonataAdmin livre de recettes bientôt!

https://github.com/sonata-project/SonataAdminBundle/issues/1546

caponica la solution est de travailler uniquement sur oneToOne relations, ai-je le droit? Dans mon oneToMany cas , ceci: $parent->$getter() renvoie une collection, et je ne sais pas comment identifier le sujet en cours. J'ai trouvé ce rapport de bug: github.com/sonata-project/SonataAdminBundle/issues/1568, qui contient un correctif pour cela, mais il est encore ouvert, donc j'espère qu'ils vont fusionner bientôt:(

OriginalL'auteur caponica

2

caponica la solution est de travailler uniquement sur oneToOne relations, ai-je le droit? Dans mon oneToMany cas , ceci: $parent->$getter() renvoie une collection, et je ne sais pas comment identifier le sujet en cours.
J'ai trouvé ce rapport de bug:
https://github.com/sonata-project/SonataAdminBundle/issues/1568, qui contient un correctif pour cela, mais il est encore ouvert, donc j'espère qu'ils vont fusionner bientôt:(

Modifier

Avec quelques recherches, il y est une solution temporaire pour cela: Fixe arriver mauvais sujet dans sonata_type_collection

En bref:

créer une classe et copypaste le contenu de ce fichier: AdminType
puis l'ajouter à vos services.yml, et de changer la classe de l'espace de noms à vous de la nouvelle classe de l'espace de noms:
```
services:
sonata.admin.form.type.admin:
    class: ACME\AdminBundle\Form\Type\AdminType
    tags:
        - { name: form.type, alias: sonata_type_admin }
```
Il a encore un bug:

aussi correctif ne fonctionne pas lorsqu'il est activé cascade_validation dans le parent docment et intégré formulaire comporte des erreurs

OriginalL'auteur hombee
0

Pouvez-vous essayer $this->getForm()->getViewData(); au sein de votre ImageAdmin? Cela devrait vous obtenez la bonne entité enfant.

Mettre $this->getForm()->getViewData() à l'intérieur de ImageAdmin::configureFormFields() semble provoquer une boucle infinie, une erreur de mémoire et un écran blanc de la mort... aïe!
Alors peut-être $formMapper->getFormBuilder()->getForm()->getViewData() vous aider?
Eh bien, qui empêche l'explosion, mais getViewData() retourne NULL même si il y a une Image sur la Page que je suis en train de modifier.
Une plus de chose que vous pourriez faire est de écouter les événements de formulaire. De cette façon, vous pourriez faire $formMapper->getFormBuilder()->addEventListener(FormEvents::POST_SUBMIT, function(FormEvent $event) { $subject = $event->getForm()->getViewData(); });. Juste de l'utilisation appropriée du type d'événement que vous avez besoin. Le problème, c'est que je n'ai pas trouver un moyen facile de modifier la forme Sonate de l'événement.
Merci pour les idées! Cependant, je ne pense pas que POST_SUBMIT aiderait... je suis en train d'afficher quelque chose sur la forme avant l'utilisateur soumet! Cependant, je vais jeter un oeil sur elle et peut-être PRE_SET_DATA aidera.

OriginalL'auteur TautrimasPajarskas

J'ai essayé toutes ces solutions, mais aucune n'a prouvé de travail.

Donc, j'ai travaillé pour trouver une solution. Ma solution est basée sur caponica de la solution, mais le travail sur oneToMany cas. Tha solution que j'ai trouvé est une solution de contournement, mais fonctionne bien.

Il fonctionne à l'aide de la session.

public function getCurrentObjectFromCollection($adminChild)
    {
    $getter = 'get' . $adminChild->getParentFieldDescription()
                               ->getFieldName();
    $parent = $adminChild->getParentFieldDescription()
                   ->getAdmin()
                   ->getSubject();
    $collection = $parent->$getter();

    $session = $adminChild->getRequest()->getSession();
    $number = 0;
    if ($session->get('adminCollection')) {
        $number = $session->get('adminCollection');
        $session->remove('adminCollection');
    }
    else {
        $session->set('adminCollection', 1 - $number);
    }

    return $collection[$number];
}

Et vous obtenez le bon objet dans l'admin par:

    $object = $this->getCurrentObjectFromCollection($this)

Ainsi, lorsque le parent doit afficher la liste des enfants admins, chaque enfant administrateur pour exécuter cette fonction et mettre à jour le paramètre session. Lorsque tous les éléments ont été prises, le paramètre session est supprimée.

Ce code est fait pour les listes avec seulement 2 éléments, mais peut être mis à jour pour n'importe quel nombre d'éléments.

Espérons que cela aide quelqu'un 🙂

OriginalL'auteur Alex Togo

0

J'ai eu le même problème et je suis en mesure de le faire à travers la "Coutume Extension de Type de Formulaire", pour lequel la documentation est donnée sur le lien "http://symfony.com/doc/current/cookbook/form/create_form_type_extension.html" .

C'est la solution parfaite ..

OriginalL'auteur Ajeet Varma

Vous devez vous connecter pour publier un commentaire.