Statyczne pole - utrata danych

0

Witam!

Posiadam trzy klasy w osobnych plikach.

astatic.php

<?php

	class A
	{
		private static $var;
		
		public static function Set($string)
		{
			self::$var = $string;
		}
		
		public static function Get()
		{
			echo self::$var;
		}
	}

	
	
?>

bstatic.php

<?php

	include "astatic.php";

	class B
	{
		public function __construct()
		{
			A::Set("test");
			header("Location: cstatic.php");
		}
		
	}
	
	
	
	$obj = new B();
	
	
?>

cstatic.php

<?php
	
	include "astatic.php";
	
	class C
	{
		public function __construct()
		{
			echo "Message from C: ";
			A::Get();
		}
	}
	
	$obj2 = new C();
	
?>


Moim celem jest inicjalizacja statycznego pola z klasy A z poziomu klasy B, a następnie przekierowanie do pliku klasy C, która to pole powinna odczytać.
Gdy umieściłem wszystkie klasy w jednym pliku i nie wysyłałem headera, wtedy wszystko działało. W tej chwili klasa C wyrzuca tylko napis: "Message from C:" bez wartości pola, a var_dump() statycznego pola z klasy A zwraca null.

Cała sytuacja sprowadza się do tego, że mam kontroler, do którego przesyłam dane w postaci POSTa, on wykonuje odpowiednie operacje i ustawia (lub nie) statyczne pole w pewnym modelu. Jego następnym zadaniem jest uruchomienie widoku, który to statyczne pole powinien odczytać, a uruchomienie chciałem wykonać za pomocą headera, jednak widzę, że mam do czynienia z utratą danych w wyniku tego.

Czy powinienem umieścić te klasy w jednym pliku za pomocą chociażby include'ów i sprowadzić wszystko do sytuacji, w której widok i kontroler korzystają z jednego obiektu modelu?

P.S. Proszę się nie obrażać na tego statica i sposób zwracania pola statycznego przez echo, to tylko dla testów ;)

0

Aplikacja w PHP to aplikacja bezstanowa. Pomiędzy każdymi żądaniami wszystkie dane ze zmiennych są gubione.

Być może uratuje Cię utworzenie sesji i korzystanie z $_SESSION, ale to zapewne tez nie będzie dobra opcja - pamiętaj, że user może otworzyć sobie dwie karty z Twoją stroną - w zależności od tego co dalej z tymi danymi robisz - może stanowić to problem.

0

Czyli nie jest herezją wrzucenie kontrolera, widoku i modelu do jednego pliku (przez include'a, a nie tak fizycznie) i wykonanie wszystkich operacji po jednym odświeżeniu?

0

Nie da się "wrzucić do pliku" przez include. Include to include, łączenie plików to coś innego.

Ciężko ogarnąć co ty tam w ogóle lepisz, ale nie widzę potrzeby zapisywania czegokolwiek do zmiennych, zmuszenie klienta do przeładowania strony, co spowoduje dokończenie operacji na danych i dopiero "zamknięcie" algorytmu przetwarzającego te dane. Jeżeli nie ma potrzeby czegokolwiek prezentować w międzyczasie klientowi, ani dopytywać o dodatkowe dane, to zdecydowanie zrób to w jednym żądaniu, a kwestię porządku kodu na pewno da się jakoś dopracować, no ale w Twoim przypadku tego kodu nie mamy za wiele, więc więcej podpowiedzi nie będzie na bieżącą chwilę ;)

0

Mam okno logowania, które jest widokiem. Z jego poziomu wysyłam dane do kontrolera, który jest połączony z modelem udostępniającym dane z bazy, które są przez wspomniany kontroler analizowane i następnie jeśli są poprawne to kontroler przekieruje na stronę główną, a jeśli nie, to chciałbym wyświetlić okno z błędem. I teraz nie wiem, czy to okno powinno być zrobione, jako osobny widok, czy powinna się wykonać modyfikacja widoku logowania, ale nie wydaje mi się, żeby ta druga opcja była dobra. Problemem jest ewentualny widok prezentujący błąd, bo on musi skądś wziąć ten komunikat (chciałbym, żeby to okno nie było na sztywno przypisane do błędu logowania, ale żebym mógł z jego poziomu wyciągać komunikat o błędzie). Mam również model do obsługi błędów, który moim zdaniem powinien trzymać komunikaty i z niego widok błędu by sobie pobierał komunikat.

Inna opcja to wysyłanie POSTa na widok logowania, do którego będzie podłączony kontroler, model itd. Potem mógłbym jakoś dobrać się do pola modelu, w którym będzie ewentualny error i go wyświetlić, ale nie wiem, jak to zrobić, jeśli chciałbym uruchomić nowy widok, który będzie prezentował okno z błędem.

0

I teraz nie wiem, czy to okno powinno być zrobione, jako osobny widok, czy powinna się wykonać modyfikacja widoku logowania, ale nie wydaje mi się, żeby ta druga opcja była dobra.

Obok komunikatu błędu chcesz chyba wyświetlić logowanie raz jeszcze, prawda? Chyba nie chcesz pokazać wiadomości "złe hasło" i zmuszać użytkownika, żeby sobie kliknął jeszcze raz i dopiero wrócił znowu do okna logowania?

Mam również model do obsługi błędów, który moim zdaniem powinien trzymać komunikaty i z niego widok błędu by sobie pobierał komunikat.

To dlaczego tego nie użyjesz?

0

@dzek69 Zastosowałem pewne rozwiązanie, chciałbym abyś zweryfikował, czy jest to w granicach rozsądku.

Do konstruktora widoku logowania wprowadziłem parametr, który jest ustawiany w zależności od zawartości pola błędu z modelu obsługującego błędy.
Jeżeli w polu znajduje się komunikat, wtedy instancjonuję obiekt widoku logowania z parametrem true, co skutkuje pobraniem przez ten widok pola błędu z modelu. W przeciwnym razie instancjonuję obiekt z parametrem false i pobieranie błędu nie następuje.

Model obsługujący błędy zawiera statyczne pole i statyczne metody do jego ustawiania i zwracania. Wiem, że "statiki" są raczej nieakceptowalne, jednak chciałbym ich w tym przypadku użyć.

Czy takie rozwiązanie jest do przyjęcia?

Przy okazji: Czy kontroler może być odpowiedzialny za ustawianie sesji?

1 użytkowników online, w tym zalogowanych: 0, gości: 1