Forum PHP.pl

Posiadam stronę w 40% opartą o ajax. Strona napisana obiektowo według wzorca MCV. Jednak doszedłem do obsługi AJAXu na stronie i mam problem z jego obsługą po stronie php. Jak zrobić to optymalnie?

[PHP] pobierz, plaintext 
<?php
public function acceptModerKoment($id, $user) { //class coment
 
		$zapytanie = db::query("UPDATE `komentarze` SET `mod` = '1' WHERE (`id` = '$id' AND `user` = '$user')");
		if($zapytanie) {
			echo 'ok';
		} else {
			echo 'Wystąpił błąd podczas moderacji komentarza';
		}
	}
 
	function moderacja() {
		$id = addslashes($_POST['id']);
		$typ = addslashes($_POST['typ']);
 
		if($typ == 'usun') {
			echo coment::delateModerKoment($id, $_SESSION['zalogowany']);
		}
		else if($typ == 'dodaj') {
			echo coment::acceptModerKoment($id, $_SESSION['zalogowany']);
		}
	}
?>
[PHP] pobierz, plaintext 

Mija to się z wzorcem MCV i jest nieporęczne bo mogę wykorzystać to tylko w tym przypadku...

[PHP] pobierz, plaintext 
<?php
public function naruszenie($user, $foto, $kto) { //class glowne
		$zapytanie = db::query("INSERT INTO `naruszenia` ( `user` , `foto`, `kto` )VALUES ('$user', '$foto', '$kto')");
		if($zapytanie) {
			return true;
		}
	}
 
	function naruszenie() {
		$foto = addslashes($_POST['foto']);
		$user = addslashes($_POST['user']);
		if(!empty($_SESSION['zalogowany'])) {
			if(glowne::naruszenie($user, $foto, $_SESSION['zalogowany'])) {
				echo "Dziękujemy za zgłoszenie";
			} else {
				echo "Zgłoszenie już istnieje w bazie";
			}
		} else {
			echo "Aby zgłosić naruszenie musisz być zalogowany!";
		}
	}
?>
[PHP] pobierz, plaintext 

A to tworzy śmietnik w kodzie przy dłuższych komunikatach i treściach przesyłanych AJAXem.


webdicepl
Poprawiono ;P

Ten post edytował wlamywacz 20.04.2008, 20:28:30

Zmień tytuł tematu, forum to nie podwórko.

Jeżeli tak wygląda Twój kod, to ja tu nie widzę nigdzie MVC i przez to masz problemy z obsługą ajaxa.

1. echo w klasach? wtf?!
2. kto tu tyle metod statycznych nawalił, a i w niektórych miejscach self użyć by można
3. raz zwracasz raz echo, trochę konsekwencji
4. nazewnictwo - najlepiej po angielsku - całość i wszędzie, a nie raz tak, raz tak

Ten post edytował Hacker 20.04.2008, 21:06:49

Chłopie to są przykłady w drugim wyraźnie widać że to kombinowanie z MCV. Nie pokazałem kontrolera bo po co ? Model to public function naruszenie a ja mam problem z widokiem...

To może daj jakiś lepszy kawałek kodu i powiedz co jest u Ciebie modelem, co kontrolerem, a co widokiem.

Przeczytaj całość i nie rób offtopu

[PHP] pobierz, plaintext 
<?php
function request($name) {
		if(method_exists($this, $name)) {
			$this->$name();
		} else {
			$this->error();
		}
	}
?>
[PHP] pobierz, plaintext 

Cały mega kontroler (po co mi więcej?)

Sprecyzuje: Jak pogodzić model z widokiem aby kod nie był śmietnikiem (obsługa odpowiedzi typu: "ok" itp.) a kod był według wzorca MCV

Huh nie rozumiem jednego: po co ludzie trzymają sie MVC skoro im jest niewygodnie? To takie wymuszanie chorego wzorca na siłę. Ja np. u siebie nie mam modeli - mam wzorzen VC i jestem bardzo zadowolony =). Niby mam napisaną funkcje do ładowania modeli ale nie korzystam bo jest mi po prostu niewygodnie.

W twoim przypadku mozesz zwracać różne wartości i w zależności od tego jaka wartość zostanie zwrócona generować odpowiedni komunikat.

A tak spytam jeszcze z ciekawości (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) . Z czego pobierasz dane? Tzn czy planujesz coś jeszcze oprócz bazy? (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Jedynie baza innej możliwości nie przewiduje (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

@SHiP
Jak nie wiesz po co jest MVC, to Twoja sprawa, bo ja wiem co daje rozdzielenie tych elementów. Jak mam coś zmieniać/poprawiać, nie mam problemu, wystarczy w jednym miejscu coś zmienić i już wszędzie mam uwzględnione, jak nie masz warstwy modelu, to cokolwiek zmienisz w pobieranych danych, czy źródle, od razu musisz przejrzeć gdzie z tego było korzystanie. A to tylko cząstka korzyści.

To mi przypomina kolegów, którzy mają SVN, ale czasem przesyłają pliki między sobą, "bo coś nei działa", no a to skutkuje dalszymi kłopotami, jak spytałem dla czego tak robią "bo łatwiej/szybciej" co mija się z prawdą.

Co do głównego tematu dyskusji, to właśnie jak koledzy mówią, tu nie ma wydzielonej warstwy widoku.cA w tym przypadku to jest ważne.

Dlatego pytam jak wy rozwiązalibyście, macie rozwiązane ten problem? Dla mnie tworzenie nowej klasy widoku tylko po to aby obsłużyć te kilka odpowiedzi troszkę mija się z celem ?

Zależy jak masz napisany widok. Ja przy wysyłaniu zapytania AJAXEM wysyłam dodatkową zmienna np &ajax=1 Później w Pluginie View mam if($this->getInt()>0) { nie wyswietlaj topa i stopki }. A komunikat robie jak każdy inny, do templatki go wrzucam, bo od tego są.
I wychodzi, że jak dam &ajax=ok to zmienia się tylko to, że nie pokaże mi topa (logo itd.) oraz stopki.
Ajaxa obsługuje jak normalne zapytanie i moim zdaniem tak powinno być!

Niezbyt Cię rozumiem jak chciałeś mi pomóc... Po co mam odpalać template do wysłania komunikatu "ok" skoro to musi być bardzo wydajne ? Lepiej zrobię sobie do każdej akcji AJAX osobna funkcję w widoku i tyle

Ogólnie powinieneś mieć tak, że przekazujesz dane do warstwy widoku i tyle, czy będą przekazane do systemu szablonu, zapisane do pliku, czy wysłane "w świat" już akcji nie powinno obchodzić.
Czyli zamiast jak normalnie przekazywać do systemu szablonów, to tworzysz lekką warstwę widoku która nic nie prasuje tylko wyrzuca dane bez formatowania.
Oczywiście to jest to co chcesz robić, bo moim zdaniem jednak powinny być szablony, aby to PHP tworzył to co ma być wstawione na stronie, pomijam przypadki, kiedy się zmieniają tylko dane, a widok jest ten sam, bo wtedy to wystarczy pobrać dane.
Sam nie używałem AJAX, bo nie musiałem, a inne rzeczy bardziej mnie interesują, ale z tego co pamiętam do niego można przekazywać dane ubrane w pewne formaty, jeden to XML drugi jakiś, który jest od razu, bez przetwarzania dostępny w JS. Ale to jak pisałem, wystarczy zmienić widok i zmieni się sposób prezentacji danych.

Chodziło mi o to, że przekazujesz to do warstwy widoku i (u mnie) ja w Plugin_Template dziedzicze po OPT. nadpisuję funkcję np. display();

[PHP] pobierz, plaintext 
<?php
function display($sFile)
{
if($this->bAjaxRun)
{
echo $this->sMessages; // tutaj wyswietlaj to co przekazujesz do templatki :) np porzez assign('ajax', 'message'); zeby na przyszlosc zachowac jendolitosc, bo dajbóg chciałbyś coś zmieniać
} else {
parent::display($sFile);
}
}
?>
[PHP] pobierz, plaintext 

Chodzi, żeby zachować jednolitość. W przyszłości jednak będziesz chciał obsłuzyć to w tmeplatcę, to zmienisz tylko w pluginie template, zamiast babrać wszędzie.

Ten post edytował bim2 22.04.2008, 20:31:56

@bim2
A nie powinieneś użyć strategi? Bo takie ify...

W wypadku ajaksu tworze dodatkowe kontrolery/metody które zwracają dane w formacie JSON.
W kontrolerze/metodzie wystarczy wtedy echo json_encode( $data );
Co jest bardzo wygodne i chyba najszybszą metodą zwracania danych do przeglądarki w trybie XMLHttpResponse

@MMPrime
A wiesz co się dzieje potem z szybkim i wygodnym kodem, zawsze się coś pier*.
Najlepiej wrócić do proceduralnego kodu, tam przecież wszystko było szybkie i wygodne (IMG:http://forum.php.pl/style_emoticons/default/dry.gif)

JSON, no właśnie o tym sposobie wracania mówiłem, ale nie pamiętałem nazwy.

Do tego jeśli chcecie pisać proceduralnie, to przenieście temat.

@Sedziwoj
Strategi? (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Człowiek się ciągle uczy i okazuje się, że coraz mniej umie. :]

Dobra teraz podsumuje troszkę.
Mamy akcję

[PHP] pobierz, plaintext 
<?php
class Action_News extends Application_Action {
 public function delete()
 {
   if($this->oDb->query('DELETE FROM news WHERE id='.$_GET['id']))
   {
	 $this->sMessage = 'Wszystko przebiegło pomyślnie';
   } else {
	 $this->sMessage = 'Nie udało się usunąć newsa';
   }
	 $this->getView('News', 'delete');
 }
}
?>
[PHP] pobierz, plaintext 

oraz View:

[PHP] pobierz, plaintext 
<?php
class View_News extends Application_View {
 public function delete()
 {
   $this->assign('message', $this->sMessage);
   $this->parseAjax();
 }
?>
[PHP] pobierz, plaintext 

no i parse ajax:

[PHP] pobierz, plaintext 
<?php
public function parseAjax()
{
   echo $this->get('message'); //mozna jeszcze bawic sie z kodowaniem i duperele
   $this->bShowFooter = false;
}
?>
[PHP] pobierz, plaintext 

Ten post edytował bim2 23.04.2008, 09:52:44

Programowanie Web jest kompromisem pomiędzy szybkością działania a programowaniem idealnym(OOP).
W tym wypadku nowe metody + JSON sprawdzają się doskonale gdyż funkcjonalność metod ajaksu w 99% jest inna niż jawnego wywołania adresu url w aplikacji.

Nie ma też sensu tworzyć szablonów dla funkcji JSON, więc formatka echo json_encode($data); w kontrolerze jest jak najbardziej zgodna z zasadami MVC/OOP

---

Poza tym do ajaksu nie powinniśmy przesyłać w ogóle kodu html ponieważ to ogranicza możliwości, wysyłamy dane które rzeczywiście będą użyte w JS.

Ten post edytował MMPrime 23.04.2008, 10:15:19

Ale kto chce wysyłać html? Jeśli coś piszemy, bądźmy konsekwentni i nie róbmy raz $this->getView(); a raz echo json();