Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [ZendFramework] podwójny warunek Where.
Forum PHP.pl > Forum > PHP > Frameworki
istrd
Witam,
Mam takie pytanie jak użyć podwójnego warunku where.
Próbuje tak:

  1. $exg = new Application_Model_DbTable_Exchange_game();
  2. $where= array('user_suggest'=>$id,
  3. 'approved'=>1);
  4.  
  5. $rows=$exg->select()->where($where);
  6. $rows=$rows->query();
  7. $rows=$rows->fetchAll();


Lecz dostaję error. Kiedyś używałem w ten sposób i działało teraz nie wiem co jest.

Zend_Db_Statement_Exception: SQLSTATE[42S22]: Column not found: 1054 Nieznana kolumna 'Array' w where clause
melkorm
  1. $query = $exg->select()->where('user_suggest =?', $id)->where('approved = ? ', 1);
  2. $rows = $exg->fetchAll($query);
Fluke
A nie lepiej w taki sposób:

  1. <?php
  2. $table = new Application_Model_DbTable_Exchange_game();
  3. $select = $table->select();
  4. $select = $select
  5. ->where("user_suggest =:suggest AND approved =:appr")
  6. ->bind(array(
  7. ":suggest" => $suggest,
  8. ":approved" => $approved
  9. ));
  10.  
  11. $rowset = $table->fetchAll($select);
  12. ?>
CzarnyGsm
A nie jeszcze lepiej zrobić to odwołaniem do Modelu (w końcu jest to framework typu MVC i trzymamy się jakiś standardów):

Ja zrobiłbym to tak:
  1. class Application_Model_ExchangeGame extends Zend_Db_Table_Abstract {
  2.  
  3. protected $_name = 'exchange_game';
  4.  
  5. public function funName($suggest, $approved){
  6. $select = $this->select();
  7. $select->from($this->_name)
  8. ->where('suggest = ?', $suggest)
  9. ->where('approved = ?', $approved);
  10. $rows = $this->fetchAll($select);
  11. return $rows;
  12. }
  13. }


Odebranie danych w kontrolerze i np. przekazanie ich do widoku, gdzie operujemy później tymi danymi:
  1. public function fooAction(){
  2. ...
  3. $modelExchangeGame = new Application_Model_ExchangeGame();
  4. $rows = $modelExchangeGame->funName();
  5. $this->view->rows = $rows;
  6. ...
  7. }
Fluke
@CzarnyGsm
Po co w select dajesz from ? bez tego się obejdzie smile.gif

Nie wiadomo ile kolumn zawiera dana tabela i jak wygląda jej użytkowanie(jakie mogą być zapytania do niej). Bo po co pisać 10 różnych metod jak zawsze będziemy wykorzystywać 1 metodę tylko raz smile.gif

Ostatnio się zastanawiam nad modelem i widzę bez sens pisania metod w modelu chyba, że gdy wykorzystujemy je kilkakrotnie w kontrolerach.

Każdy robi jak kto woli smile.gif
melkorm
Cytat
Ostatnio się zastanawiam nad modelem i widzę bez sens pisania metod w modelu chyba, że gdy wykorzystujemy je kilkakrotnie w kontrolerach.


To życzę miłego testowania takich kontrolerów.

Ogólnie jak najwięcej rzeczy związanych z logiką biznesową aplikacji i pobieraniu skądś danych powinny być w modelach. Też kiedyś myślałem że będę sobie pisał zapytania w kontrolerach i będzie luz bo po co dla każdego zapytania osobna metoda itp. bardzo się na tym przejechałem od tamtego momentu wszystko w modelach smile.gif

PS. Polecam poszukanie tematu : "Thiny Controllers Fat Models"
Fluke
@melkorm

A w kontrolerze można zapisywać bądź aktualizować rekordy w bazie danych czy raczej też to należy do modelu questionmark.gif
CzarnyGsm
Cytat(Fluke @ 7.05.2012, 22:09:40 ) *
@CzarnyGsm
Po co w select dajesz from ? bez tego się obejdzie smile.gif
Nie wiadomo ile kolumn zawiera dana tabela i jak wygląda jej użytkowanie(jakie mogą być zapytania do niej). Bo po co pisać 10 różnych metod jak zawsze będziemy wykorzystywać 1 metodę tylko raz smile.gif

Zgadza się, akurat tu jest to niepotrzebne, miałem zamiar podać przykład z
  1. ->from($this->_name, array(przykładowe kolumny))
, ale w ostatniej chwili zrezygnowałem z niego bo zakładającemu temat raczej chodziło o wszystkie kolumny.

Cytat(Fluke @ 7.05.2012, 22:09:40 ) *
Ostatnio się zastanawiam nad modelem i widzę bez sens pisania metod w modelu chyba, że gdy wykorzystujemy je kilkakrotnie w kontrolerach.
Każdy robi jak kto woli smile.gif

Nie jak kto woli, ale jak już piszemy w ZF to stosujmy się do jego standardów. Jest to język obiektowy, a mieszanie kodu i pisanie wszystkiego w jednym pliku tylko 'szpeci' nasz kontroler. Starajmy się być zgodni ze wzrocem MVC.

Oczywiście do autora tematu zależy wybór rozwiązania. Tylko niech nie zdziwi się jak przyjdzie mu wyjaśniać dlaczego w kontrolerze umieszcza kod, który powinien znajdować się w modelu.


Cytat(Fluke @ 8.05.2012, 11:36:22 ) *
@melkorm

A w kontrolerze można zapisywać bądź aktualizować rekordy w bazie danych czy raczej też to należy do modelu questionmark.gif

Pozwolisz, że odpowiem na to pytanie. Przykładowo jak chcesz dodać rekordy do bazy korzystając z modelu:
  1. public function fooAction(){
  2. ...
  3. //kod z pobraniem danych z ałożmy z formularza
  4. ...
  5. $modelExchangeGame = new Application_Model_ExchangeGame();
  6. $result = $modelExchangeGame->addData();
  7. if($result){
  8. //ok
  9. };
  10. ...
  11. }

Oczywiście w modelu ExchangeGame tworzysz odpowiednią funkcję addData, która dodaje rekord do bazy.
melkorm
Kontroler to tak na prawdę pośrednik, weź coś skądś (zazwyczaj model) i przekaż gdzieś (zazwyczaj widok) i w drugą stronę : odbierz coś skądś (zazwyczaj request HTTP) i przekaż gdzieś + ewentualnie sprawdź dane.

Co do ostatniego punktu ja to rozwiązuje tak :

  1.  
  2. $form = new FooForm();
  3. if($this->getRequest()->isPost())
  4. {
  5. $model = new BarModel();
  6. // walidacja tutaj (isValid) lub po stronie modelu
  7. $model->save($form, $data);
  8. }



Ogólnie większość sposobów z którymi się spotkałem to walidacja formularza po stronie kontrolera i jeżeli wszystko OK to przesłanie samych danych do Modelu który zajmuje się czystym zapisem, osobiście rozwiązuje to w taki sposób że do modelu zawsze przekazuje formularz i dane wtedy Model zajmuje się walidacją i sprawdzeniem danych i w przypadku powodzenia zapisuje (robi coś dalej z danymi), a w przypadku niepoprawnych danych wejściowych (walidacja formularza się nie powiodła) rzucam po prostu wyjątek - w tym przypadku na pewno ktoś powie że źle wypełniony formularz nie jest stanem wyjątkowym aplikacji, cóż ja to rozwiązuje w ten sposób, łatwiej mi się to testuje i mam pewność że nigdzie się nie walnąłem z true/false smile.gif

Cytat
Oczywiście do autora tematu zależy wybór rozwiązania. Tylko niech nie zdziwi się jak przyjdzie mu wyjaśniać dlaczego w kontrolerze umieszcza kod, który powinien znajdować się w modelu.


Raczej niech się nie zdziwi że zapytanie napisane z `palca` w kontrolerze będzie musiał użyć gdzieś indziej, a nie daj boże już parę razy skopiował kod i będzie musiał coś z nim zmienić, teraz szukaj wszędzie tego użycia itp., albo głupia zmiana nazwy kolumny, tak to praktycznie wszystko jest w Modelu / Modelach i mamy pewność że nic nam nie umknęło smile.gif
Fluke
A teraz pytanie odnośnie relacji w ZF.

Załóżmy, że mamy 3 tabele: users, users_files, files. Tworzymy odpowiednie modele oraz relacje między nimi.
W jednej akcji wybieramy użytkownika oraz jego pliki -> czyli piszemy stosowną metodę w Model_User questionmark.gif
W drugiej akcji wybieramy tylko użytkownika

Gdy mamy więcej tabel połączonych relacją do siebie to czy każdy sposób wyciągnięcia danych musimy opisać w modelu questionmark.gif
melkorm
Generalnie tak, na początku może się wydawać że : "OMG! Każde zapytanie inna metoda, ile tego będzie! ola-boga!", a tak na prawdę zawsze jest to skończona ilość i o wiele lepiej się pracuje z takimi modelami smile.gif


edit:
Tak, obie metody powinny się znaleźć w Model_User. Zaś np. wyciąganie plików i nazw użytkownika/ów powinno się znajdować w Model_FIle.
Fluke
Bo właśnie tak kiedyś robiłem i czasem jedną metodę wykorzystywałem tylko raz więc przeniosłem odpowiedzialność na kontrolera.
Dzięki @melkorm smile.gif

W Model_File powinno się znajdować wyciąganie plików ale czy nazw użytkowników questionmark.gif To chyba już w Model_User, czy ja coś źle rozumiem smile.gif
melkorm
Ogólnie to select w kontrolerach to nic, widziałem gorsze kwiatki, wielokrotnie widzę jak ktoś pobiera w kontrolerze adapter bazy danych i połączenie później operuje na czystym połączeniu MySql/PDO/MySqli i myśli że w 100% wykorzystuje możliwości Zend'a i jest przed wszystkim zabezpieczony =D

... ale to tak na marginesie smile.gif

PS. Dobra rada, zainteresuje się PHPUnit, bo wtedy można łatwo ocenić swój kod (chociaż nie zawsze ta zasada się sprawdza) im łatwiej pisze się Tobie testy dla Twojego kodu, tym lepszej jakości on jest smile.gif

Edit: Jeżeli masz Pliki które mają użytkowników i chcesz tych użytkowników to masz kilka rozwiązań w zależności od relacji:

1. One-to-One: Zwykły JOIN na tabelę userów.
2. Many-to-One: 2 SELECTy, pierwszy wyciąga pliki i zbiera id'ki użytkowników, drugi wybiera userów o podanych ID'kach i to mieszasz.
3. Many-to-many: praktycznie punkt drugi.

I wszystko to odbywa się w modelu : Model_File, praktycznie dla przypadku 2 i 3 możesz odpytać o te dane (użytkowników o podanych ID'kach) Model_User oczywiście smile.gif
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.