Drukowana wersja tematu

Napisany przez: Foxx 11.05.2013, 02:18:41

Załóżmy, że mamy tablicę obiektów "Pytanie" przekazaną do szablonu twig. Wyświetlamy sobie te pytania:

[HTML] pobierz, plaintext 
{% for pytanie in pytania %}
  {{ pytanie.nazwa }}
{% endfor %}
[HTML] pobierz, plaintext 

I teraz załóżmy, że każde pytanie może mieć powiązany obiekt "Odpowiedź" w relacji OneToMany (jedno pytanie może mieć wiele odpowiedzi - od różnych userów).

Pytanie: w jaki sposób mogę wyświetlić przy każdym z pytań odpowiedź, która jest do niego przypięta i która ponadto należy do wybranego usera? Czyli nie po prostu odpowiedź należącą do tego pytania, ale dodatkowo, która ma parametr userId = np. 5.

Moje próby:

1. Najprościej byłoby w kontrolerze po prostu pobrać odpowiedzi do każdego z pytań skoro pobieram tam pytania. Problem w tym, że ja nie pobieram pytań w kontrolerze. W kontrolerze pobieram tylko "Karty", a w twigu pętlą pobieram wszystkie "Grupy" każdej z kart i kolejną pętlą pobieram dopiero wszystkie "Pytania" każdej grupy. Czyli nie bardzo mogę pobrać odpowiedzi bo nie dysponuję pytaniami w kontrolerze.

2. Próbowalem to zrobić przy pomocy renderowania kontrolera w twigu. Napisałem metodę, która zwraca mi odpowiedź, ale problemem jest to, że w ten sposób renderuję jakiś template w twigu i tyle. A ja potrzebuję uzyskać dostęp do tej zmiennej i móc ją użyć kilka razy w moim szablonie.

Inaczej moje pytanie można sformułować tak: jak mogę uzyskać w twigu dostęp do obiektu powiązanego z obiektem, który tam już mam, ale mogąc jednocześnie wykonać trochę bardziej złożone filtrowanie na tych powiązanych obiektach.

Dzięki za wszelkie rady.

EDIT:

Rozwiązałem problem, ale nie jestem zadowolony. W kontrolerze zrobiłem podwójnego foreacha, analogicznego do tego, który robię w twigu żeby wyświetlić pytania. I w tym foreachu tworzę tablicę z odpowedziami gdzie kluczami są identyfikatory pytań. Podaję tą tablicę do twiga no i mogę sobie jej użyć. Nie jestem zadowolony bo dwa razy robię tą samą pętlę. Nie bardzo mogę wyeliminować pętlę w twigu bo bardzo wygodnie wyświetla mi się w ten sposób pytania uporządkowane w grupach.

Napisany przez: destroyerr 11.05.2013, 11:00:27

O ile dobrze zrozumiałem to moja propozycja jest taka:

[PHP] pobierz, plaintext 
class Answer
{
    public function getUser();
}
 
class Question
{
    private $answers;
 
    public function getAnswers()
    {
        return $this->answers;
    }
 
    public function getAnswersForUser(User $user)
    {
        return $this->getAnswers()->filter(function (Answer $a) { return $answer->getUser() == $user });
    }        
}
[PHP] pobierz, plaintext 

Napisany przez: Foxx 11.05.2013, 11:07:25

Rozumiem, to by rozwiązało problem, ale czy takie metody nie powinny znaleźć się w repozytorium encji zamiast w samej encji? Jak ocenić czy metoda może znaleźć się w encji czy już powinna iść do repozytorium?

Napisany przez: Crozin 11.05.2013, 11:15:42

W tym przypadku najprawdopodobniej pobranie odpowiedzi dla danego użytkownika powinno być przerzucone do repozytorium, chociażby ze względu na potencjalnie ogromną ilość danych do pobrania i przetworzenia w przykładzie podanym przez @destroyerr. Czyli:

[PHP] pobierz, plaintext 
$questionsRepository = ...;
 
$questions = $questionsRepository->findAllAnsweredBy($user);
[PHP] pobierz, plaintext 

Napisany przez: destroyerr 11.05.2013, 13:33:20

Podstawowym kryterium jest to czy encja operuje na danych które posiada, tzn. znajdują się w jej grafie. Tak jest w tym przypadku, inaczej byłoby dla relacji Answer ManyToOne Question. Jeśli problem dotyczyłby innego pytania lub odpowiedzi nie powiązanych z tym pytaniem to wtedy faktycznie pozostaje repozytorium. Reszta to optymalizacja.



Tego nie wiemy. Skoro tak gdybamy to być może w Twoim przykładzie powinieneś jeszcze uwzględnić pobieranie pytań tylko dla konkretnych odpowiedzi. Dodatkowo znowu trzeba by indeksować tablicę kluczem głównym pytania. Dla mnie to jest podejście którego staram się unikać na rzecz jasno zdefiniowanych struktur. Dopiero teraz zauważyłem, że Twój kod pobiera pytania na które odpowiedział użytkownik a nie odpowiedzi. Chyba nie zrozumiałem Twojej koncepcji.
Wracając do optymalizacji to żeby nie pobierać zbyt wielu danych możemy skorzystać z http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/working-with-associations.html#filtering-collections.

Napisany przez: Foxx 11.05.2013, 13:43:19

Dzięki za odpowiedzi.

Jeszcze pojawiło mi się takie pytanie: jeżeli chciałbym pobrać dane, które nie znajdują się w grafie encji to czy mogę stworzyć metodę w repozytorium, która te dane pobierze, a następnie metodę w encji, która wywoła sobie tą metodę z repozytorium i następnie użyć jej w twigu? Czy to już może jest zniszczenie całej tej idei?

Napisany przez: destroyerr 11.05.2013, 14:23:23

Encja nie wie o istnieniu repozytorium więc takie rozwiązanie odpada.

Napisany przez: Crozin 11.05.2013, 15:06:57

@destroyerr: Założyłem po prostu, że najprawdopodobniej autora interesuje jedynie mały fragment potencjalnie dużej kolekcji odpowiedzi na dane pytanie (filtrowanie wg użytkownika). Innymi słowy, dokładnie to co podlinkowałeś z dokumentacji Doctrine.

@Foxx: Encja powinna ograniczyć się do względnie prostych metod operujących wyłącznie w obrębie grafu relacji encji. Powinieneś raczej utworzyć metodę w repozytorium, która jako argument przyjmuje encję i zwraca jakieś wyniki - absolutnie nic nie stoi na przeszkodzie byś w Twigu korzystał z obiektu repozytorium. Ba! Jest to prawidłowe rozwiązanie z punktu widzenia MVC!

Napisany przez: Foxx 11.05.2013, 15:39:17

@Crozin: jak mogę w takim razie skorzystać z metody z repozytorium w twigu? W book znalazłem tylko sposób na renderowanie kontrolera, a użycie metody z repozytorium byłoby dla mnie idealne, ale gdy tego szukałem to trafiałem tylko na wypowiedzi takie jak tu
http://stackoverflow.com/questions/11754077/how-can-i-access-repository-functions-in-twig-template-in-symfony2
czyli "you shouldn't do this".

Napisany przez: Crozin 11.05.2013, 16:16:49

Przekaż repozytorium jako zmienną dla szablonu:

[PHP] pobierz, plaintext 
// kontroler:
return $this->render(..., http://www.php.net/array('answersRepository' => $this->get('....'));
 
// TWIG:
{% for answer in answersRepository.findBy...(user) %}
  ...
{% endfor %}
[PHP] pobierz, plaintext 

Z tym you sholdn't nie zgodziłbym się. Logika biznesowa jest ukryta wewnątrz repozytorium. Istotne jest tylko to, by metoda findBy...() zwracała już "czyste" dane gotowe do bezpośedniego wyświetlenia.

Napisany przez: Foxx 12.05.2013, 12:48:44

Dzięki wam obojgu za pomoc.