ďťż
Podstrony
|
telcocafeKlasa: http://www.unit1.pl/pb-823Na początku próbowałem przepisać moduł prywatnych wiadomości w stylu proceduralnym. Ze względu na dużą ilość instrukcji warunkowych, gdzie trzeba wysłać odmienne zapytania (z innymi danymi lub parametrami) oraz FAKT, że niektóre moduły mogą też wysyłać prywatne wiadomości do użytkowników, napisałem klasę. Dobra decyzja? Nie rozwiązuje to problemów całkowicie. Operacje możliwe do wykonania to: 1) Wysłać nową wiadomość 2) zapisać ją do kopii roboczych (nie wysyłać) 3) wysłać zapisaną kopię do użytkownika (tutaj najlepszym wyjściem będzie chyba UPDATE) 4) zapisać wysłaną wiadomość także do folderu "wysłane" (opcjonalnie) 5) zaktualizować kopię roboczą (gdy użytkownik ją zmienia) 6) ??? Jak przepisać klasę, aby wszystkie operacje wykonywało się łatwo, a kod nie stracił na wydajności? Przykład: aktualizując kopię roboczą, zmieniamy tylko: tytuł, treść, odbiorcę i opcje. Wysyłając ją, zmieniamy status, właściciela i pole "usr" (wtedy zawiera ID nadawcy). Znów 2 zapytania? Czy aktualizować wszystko podczas 1? W pliku edycji prywatnych wiadomości oprócz instrukcji warunkowych i komunikacji z klasą wykonuję jeszcze kilka operacji, gdzie mogą wystąpić błędy (np. gdy dodaje wiadomość do "wysłanych", a limit jest przekroczony) czy "brak wiadomości". Dlatego dodałem referencję $errRef. Jak przepisać kod, aby wszystkie operacje (zważając na ich zawiłość, różnice) wykonywało się łatwo, a klasa stała się elastyczna? Może za dużo lub za mało kodu tam umieściłem? Może zamiast proporcji (zmiennych klasy) lepiej użyć tablicy z danymi (do, temat, itp.)? Ostateczność - mogę wykorzystać gotową klasę na zasadach GPL. MVC - tak to się robi. SQL jedno, HTML drugie, PHP trzecie. Czyli w klasie powinienem umieścić tylko metody: add(), modify(), delete() i ewentualnie errors() / userID(), które wywoływałby tylko plik nadzorujący cały proces? A co ze statusem wiadomości? Też powinno się go "ręcznie" ustalać? Chcę umożliwić innym modułom łatwe wysyłanie wiadomości PW. klasa modelu zawiera metody z poszczególnymi operacjami SQL - dodanie/usunięcie/itd. kontroler to metody odpowiedzialne za widoki - szablony dodawania wiadomości, czytania itd. Jak chcesz wysłać PW z innej klasy to odwołujesz się tylko do modelu PW :) Dla jednej klasy, nie ma koniecznie sensu aby instalować w tym MVC, choć to na pewno bardzo dobre rozwiązanie. I tlyko uwaga do pierwszej metody - errors. zamiast global użyj referencji do $GLOBALS['lang']; if($error) { if($this->errorMode === 'EXCEPTION') { throw new Exception($e); } elseif($errRef) { return true; } else { return $error; } } A zamiast tego switch i będzie wydajniej trochę :) Jeszcze jedno pytanie. Przechowywać dane dla zapytania w tablicy $data, czy w proporcjach (zmiennych) obiektu PM? http://www.unit1.pl/pb-840 Najprościej byłoby utworzyć tablicę, aby od razu ją przekazać do PDOStatement::execute($data); Nie tak łatwo. Spójrzcie na rozgrzebany kod wysyłania wiadomości: http://www.unit1.pl/pb-839 - trzeba rozważyć różne przypadki. W POST wysyłam login użytkownika. Skrypt zamienia go na ID - PM::userID. Problem w tym, że ID odbiorcy zostanie zapisany do bazy raz w polu owner (gdy wysyłamy PW), a innym razem w usr (zapisujemy w kopiach roboczych). Zastosowałem pole owner, aby łatwo liczyć i wyświetlać wiadomości, które należą do użytkownika. Może są lepsze rozwiązania? Użytkownik Ferrari edytował ten post 27 lipiec 2008, 08:55 |
|||
Sitedesign by AltusUmbrae. |