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

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

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 . Z czego pobierasz dane? Tzn czy planujesz coś jeszcze oprócz bazy?

Jedynie baza innej możliwości nie przewiduje

@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.

@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

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? 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 

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.

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();

Patrząc po Twoim listingu z postu wyżej widzę już że chcesz wysyłać nadmiar danych. Przekazujesz całe komunikaty choć wystarczy wysłać informację true/false, całą resztę niech wykona JavaScript.


Nie praktykuję wysyłania danych przez 3 metody, dla samej idei. Jeżeli z zawartością było by dalej coś robione to można się odwołać do widoku, jednak skoro większość funkcjonalności ajaksowej ogranicza się do stwierdzenia true/false to nie ma to najmniejszego sensu.

Za dużo? Moje serwisy są wielojęzykowe, dlatego zamiast przekazywać tablicę z językami do js, w php to obrabiam i wysyłam do ajaxa. Jeśli jest błąd to wysyłam 0, ale jeśli się powiedzie to wiadomość.

Zależy do czego co używasz True/false dobrze jest wysyłać, ale zostawiając strukturę kodu. Zresztą, co jeśli user ma wyłączony javascript? Biała strona? Tak pokaże mu się odpowiednia wiadomość. :]

Jak Ty to sobie wyobrażasz ? Ja wysyłam do strony ogromną tablice w której znajdują się: komentarze i parametry. Jak Ty sobie to wyobrażasz przez obsługę true i false ?

Ja natomiast robię serwisy SEO Friendly także Twoje rozwiązanie mnie nie zadowala, zwłaszcza w wypadku wielojęzyczności. Dokument HTML jest również dokumentem XMLowym więc można nim dowolnie manipulować za pomocą JavaScriptu.


Co to ma dorzeczy skoro mówimy o rodzaju zwracanych danych do JavaScript, jeżel będzie on wyłączony to u Ciebie także skrypt nie zadziała.

--
Włamywacz, zależy kto czego potrzebuje. Prawidłowy serwis powinien wysyłać jak najmniej danych za pomocą ajaksu, z mojego doświadczenia wiem że 99% ajaksowych metod to true/false.

A więc ja jestem w tym 1% bo jak sobie wyobrażasz przesłanie np. 30 komentarzy każdy to 3x div i do każdego treść ? Ja wysyłam gotowy xhtml i nie mam problemów

W formacie JSON.

Nie znam serwisu o jakim mówisz, jednakże nie widzę sensu wysyłania komentarzy ajaksem jeżeli nie jest to serwis typu YuoTube gdzie jakaś akcja( w tym wypadku film) wykonywana w tle nie może zostać przerwana.

Wysyłasz tylko dane, takie gołej jak w bazie, a JS na podstawie szablonu tworzy dynamicznie elementy i je umieszcza na stronie.
Tylko, że ja nie znam jakiejś metody szablonów, tak aby za każdym razem nie pisać dedykowanego rozwiązania, tylko jak np. w Smarty uzupełniać wybrane miejsca (powtarzalność już na poziome JS można rozwiązać)



Bo robisz SEO Friendly stronę, jak założymy że artykuły z listy też mogą być ładowane dynamicznie, to już do nich komentarze też są, do tego nawet jak masz artykuł, to nie musisz mieć od razu komentarzy tylko "pokaż komentarze" a tu już ładujesz AJAX aby nie ładować reszty strony.

Koszmarne rozwiązanie, nie mówiąc już o SEO, nawet dla usubility serwisu to zabójstwo.

W tym problem jak obsłużyć te dane do szablonu ? A i jeszcze trzeba oddzielić parametry od danych. A to dokładnie galeria z komentarzami totalnie bez przeładowań lecz działa również bez js

SEO tak, a co z usability? Przecież lepiej aby doładowało szybko komentarze, niż trzeba czekać na przeładowanie całej strony. To rozwiązanie przyspiesza, do tego może lepiej wyglądać.

wlamywacz: to już musisz sobie w JavaScript zaprojektować jak obsłużysz te dane, choć istnieją systemy szablonów a'la Smarty dla JavaScript choć osobiście ich nie polecam.

Sedziwoj: Jak podesłać odnośnik do artykuły znajomemu skoro jest on wywoływany przez ajax. Adres URL się nie zmienia, Z komentarzami jest już mniejszy problem bo tego zazwyczaj się nie przesyła, ale SEO się tutaj kłania.

Najlepszym miejscem na ajax to panele użytkownika/panele administratorów + alias dla funkcji zmieniających tylko statusy - drobne aktualizację typu "Zgłoś temat do moderatora"

No i shoutbox.

@MMPrime
Jak co to ma do rzeczy? Jak robie jakiś odnośnik do uruchomienia AJAXa to zawsze nadaje mu odpowiedni atrybut href="", żeby jeśli user wyłączy js, przeniesie go na stronę i cofnie.

Mówię o artykułach w obrębie jednej strony, czyli masz listę i jeden z niej wyświetlony, nie mówię o zewnętrznych, bo to było by całkowicie bez sensu.
Co do SEO, to chyba trzeba by było zrobić warunek jak nie ma JS to przekierowanie na stronę z sztywno (generowane przez PHP) umieszczonym artykułem.
Czyli zrobić normalna stronę, a potem dodać AJAX, jak dodatkową rzecz, jeśli chodzi o ładowanie content'u, bo komunikaty nie koniecznie do SEO ale jak chce się aby chodziły strony bez JS, to też powinno być bez JS możliwość.

Kto w dzisiejszych czasach podpina shoutboksa na stronie, zupełnie jest to bez sensu. Chyba że mówimy o forach made by przemo, czy serwisach magowych gdzie widziałem sporo tego rodzaju gadżetów.


Dalej nie rozumiem, co ma do rzeczy rodzaj zwracanych danych (string/int/array/boolean) do atrybutu href, czy do tego że strona nie działa po wyłączeniu JavaScript.

Co do mapowania odnośników to u mnie w podglądzie źródła jest normalny kod html, dopiero za pomocą DOM podpinam zdarzenia.

Sedziwoj, dokładnie tak powinno być że strona jest dostępna w 100% bez JavaScript, cookie czy sesji, ajax dla mnie jest dodatkiem funkcyjnym czyli upraszczającym realizacje danej funkcji niż wyświetlanie samej treści w jakiejkolwiek formie. Systemy wielojęzykowe powinny mieć natomiast dwa rodzaje plików do realizowania komunikatów, te php'owe jak i tablicę JavaScript. Tym rozwiązaniem oszczędzamy pamięć używaną przez PHP(nie musi trzymać dodatkowych kb stringów w pamięci), ciężar ten przerzucamy na użytkownika - uwzględniając jednak cache'owanie danych przez przeglądarki także to nie jest problemem, bynajmniej dla serwera gdyż użytkownik odwoła się tylko raz po plik z tłumaczeniem JavaScript'owym.

Podstawowe pytanie: czy tak ważne jest że 3% użytkowników internetu nie używa JS ? Dla mnie te 3% nie ma znaczenia. Strona dla nich działa, można ją czytać jednak nie posiada funkcji dodawania komentarzy, ocen i to by chyba było na tyle. Po co się cofać ?

Do tych 3% należy 100% wyszukiwarek internetowych które generują zwyczajowo 90% ruchu.

Jak takie wymaganie narzuci ci zleceniodawca to nie masz wyboru.

@MMPrime
Jak to co? Gdy ktoś wpisze taki sam adres, jaki ty wysyłasz rządanie AJAXowe, to wyświetli mu się biała strona, no może tam 1. Zwracając komunikat, wyświetli się komunikat.

Oszczędzanie pamięci w php? I tak te języki musisz wczytać, żeby inne rzeczy na stronie działały. No chyba, że cała strona jest oparta na AJAXie... Nie lubie jak ktoś przeciąża mi komputer. Lubię mieć otwartych kilkanascie stron naraz. teraz sobie to skumuluj ile wychodzi tego :| Nadal będę się uparcie trzymał, że lepiej zwrócić komunikat.

Pytanie kto tam wejdzie, musiałby nasłuchiwać wyjścia na firewallu lub monitorować nagłówki wysyłane/odbierane przez przeglądarkę internetową by zdobyć adres url.


Framework mam tak napisany by żądania ajaksowe wymagały jak najmniejszej drogi przez aplikację. Po co mam ładować całe pliki językowe, skoro zwracam typ boolean lub tablicę z danymi(potem obróbka ich przez JavaScript).

Dla przeglądarki nie jest to duże obciążenie, gdyż zajmuje to tylko parę kb w pamięci i jest ładowane za pierwszym razem z adresu url, przy każdym kolejnym wywołaniu z pamięci ram. Aktualnie tworzy sie oprogramowanie przerzucając niektóre obliczenia/dane na użytkowników tak by odciążyć maszyny serwerowe - np. podstawowa walidacja danych JavaScript. Jaki jest cel odpalania całej maszyny tylko po to by sprawdzić czy pole 'username' wysłane z formularza nie jest puste. Najpierw sprawdzamy wszystko w języku client-side, dopiero gdy on powie że dane są poprawne można uruchomić server-side i w nim sprawdzić poprawność danych.

Dorzuć leniwe wywoływanie, to nie będzie potrzeby usuwać. A załadowanie dodatkowej klasy (widoku) który robi echo, jest pomijalnym obciążeniem, a sam potok przetwarzania się dzięki temu nie zmienia, więc ktoś zapozna się z jedną drogą, a jak masz inaczej, to trzeba poznawać wszystkie, wiem że to się wydaje głupie w Twoim przypadku, tylko oby przyszłość nie pokazała, że jednak będziesz miał przez to kupę roboty, bo tak zazwyczaj jest. Po to są pewne schematy, aby ułatwić nam życie, im więcej się ma doświadczenia z różnymi rzeczami, tym lepiej się to widzi.

Skróconą drogę mam jedynie w wypadku ajaksu, hm framework przełącza się w tryb 'lite' dla takich wywołań. Nie chodzi w nim by zmniejszyć obciążenie na serwerze, ale maksymalnie przyśpieszyć żądanie, ajax wtedy jest niewidoczny dla każdego wywołania niezależnie od obciążenia na dysku, ramie czy łączu.

Nie stanowi to problemu dla innych programistów z tego względu iż ajax ma jasną definicję gdzie/jak się go powinno stosować w całym systemie. Ponad to wywołanie jest takie proste że zrozumienie zasad działań nie zajmie więcej niż minutę by zrozumieć kod.

Google dodaje komentarze? Nie wiedziałem

Obsługuje formularze.
SEO to trochę większy zakres prac niż odnośniki.

A co ma dodawanie komentarza i ocenianie do indexowania ?


"Ciekawe czemu mi na starym forum nigdy nie indexowało wyników wyszukiwań może google źle wypełniał formularz?"

To już gadżety, ale dobry programista zrobi by działały bez JavaScrip a potem doda obsługę ajax. Więc tak czy owak będą one działały wszystkim.
Najodpowiedniejsza kolejność tworzenia dodatków w ajaksie jest po skończeniu całej aplikacji, dopiero wtedy można się zabrać za wstawki JavaScript'owe ponieważ one operują na powstałym kodzie HTML, a w czasie tworzenia aplikacji nie mamy pewności co do tego jak będzie on wyglądał.