Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> Nie można nadpisać POST w ciele klasy?, (wartości domyślne inputów)
markonix
post 1.04.2012, 19:14:15
Post #1





Grupa: Zarejestrowani
Postów: 2 707
Pomógł: 290
Dołączył: 16.12.2008
Skąd: Śląsk

Ostrzeżenie: (0%)
-----


Nie jest to jakoś szczególnie problematyczne ale nie umiem zrozumieć dlaczego tak jest. Kod:

  1. class jakakolwiek {
  2.  
  3. function __construct() {
  4.  
  5. $nazwaZmiennej = '_POST';
  6. $$nazwaZmiennej = array('test' => 'test nr 1');
  7. var_dump( $_POST );
  8.  
  9. $_POST = array('test2' => 'test nr 2');
  10. var_dump( $_POST );
  11.  
  12. }
  13.  
  14. }
  15.  
  16. $jakakolwiek = new jakakolwiek();


Powyższy kod wyświetli jedynie drugi fragment - tj. pierwszy var_dump wskaże, że $_POST jest puste.
Dlaczego tak się dzieje i dlaczego ten problem występuje wyłącznie w ciele klasy? Jeżeli napiszemy to poza klasą to działa zgodnie z założeniem.

Na ten problem natrafiłem gdy chciałem w aplikacji MVC przekazać do widoku zmienną _POST.
Bez MVC po prostu stosowałem $_POST = mysql_fetch_assoc(mysql_query(...
które w prosty sposób pobierało wartości domyślne do inputów (kod był poniżej update).


--------------------
Go to the top of the page
+Quote Post
tolomei
post 1.04.2012, 19:35:33
Post #2





Grupa: Zarejestrowani
Postów: 450
Pomógł: 135
Dołączył: 18.11.2010
Skąd: Wschowa

Ostrzeżenie: (0%)
-----


Wychodzi na to, że mamy dwie zmienne - lokalną $_POST i superglobalną $_POST.

  1. class jakakolwiek {
  2. function __construct() {
  3. $nazwaZmiennej = '_POST';
  4. ${$nazwaZmiennej} = array('test' => 'test nr 1');
  5.  
  6. $_POST = array('test2' => 'test nr 2');
  7. }
  8. }
  9.  
  10. $j = new jakakolwiek();
  11. var_dump(get_defined_vars());


Ale nie wiem czemu tak smile.gif


--------------------
“ Computers are good at following instructions, but not at reading your mind. ”
- Donald Knuth
Go to the top of the page
+Quote Post
solr
post 1.04.2012, 19:59:25
Post #3





Grupa: Zarejestrowani
Postów: 43
Pomógł: 8
Dołączył: 11.08.2010

Ostrzeżenie: (0%)
-----


Cytat(markonix @ 1.04.2012, 20:14:15 ) *
Nie jest to jakoś szczególnie problematyczne ale nie umiem zrozumieć dlaczego tak jest. Kod:

  1. class jakakolwiek {
  2.  
  3. function __construct() {
  4.  
  5. $nazwaZmiennej = '_POST';
  6. $$nazwaZmiennej = array('test' => 'test nr 1');
  7. var_dump( $_POST );
  8.  
  9. $_POST = array('test2' => 'test nr 2');
  10. var_dump( $_POST );
  11.  
  12. }
  13.  
  14. }
  15.  
  16. $jakakolwiek = new jakakolwiek();


Powyższy kod wyświetli jedynie drugi fragment - tj. pierwszy var_dump wskaże, że $_POST jest puste.
Dlaczego tak się dzieje i dlaczego ten problem występuje wyłącznie w ciele klasy? Jeżeli napiszemy to poza klasą to działa zgodnie z założeniem.

Na ten problem natrafiłem gdy chciałem w aplikacji MVC przekazać do widoku zmienną _POST.
Bez MVC po prostu stosowałem $_POST = mysql_fetch_assoc(mysql_query(...
które w prosty sposób pobierało wartości domyślne do inputów (kod był poniżej update).


Minuta googlowania: http://www.php.net/manual/en/language.vari...uperglobals.php

"Note: Variable variables
Superglobals cannot be used as variable variables inside functions or class methods. "
Go to the top of the page
+Quote Post
markonix
post 1.04.2012, 20:15:23
Post #4





Grupa: Zarejestrowani
Postów: 2 707
Pomógł: 290
Dołączył: 16.12.2008
Skąd: Śląsk

Ostrzeżenie: (0%)
-----


Ok, dzięki.

Teraz pytanie jak to obejść i jakoś w widoku nadpisać ten POST.
Ostatecznie zrobię oddzielną tablicę $default ale nie każdy formularz buduje za pomocą klasy i zawsze to więcej kodu..


--------------------
Go to the top of the page
+Quote Post
solr
post 1.04.2012, 20:28:36
Post #5





Grupa: Zarejestrowani
Postów: 43
Pomógł: 8
Dołączył: 11.08.2010

Ostrzeżenie: (0%)
-----


Szczerze mówiąc nie rozumiem twojego problemu. Czemu zamiast:

  1. $nazwaZmiennej = '_POST';
  2. $$nazwaZmiennej = array('test' => 'test nr 1');
  3. var_dump( $_POST );


nie zrobisz po prostu:
  1. $_POST = array('test' => 'test nr 1');
  2. var_dump( $_POST );


ewentualnie, każdy element posta sprawdzić, czy jest i jak nie ma to wtedy dopisać wartość domyślną.
Go to the top of the page
+Quote Post
markonix
post 1.04.2012, 20:35:09
Post #6





Grupa: Zarejestrowani
Postów: 2 707
Pomógł: 290
Dołączył: 16.12.2008
Skąd: Śląsk

Ostrzeżenie: (0%)
-----


Normalnie bym tak zrobił ale w MVC wartości do widoku przekazuje w taki sposób:
$this->registry->template->_POST.


--------------------
Go to the top of the page
+Quote Post
Fifi209
post 1.04.2012, 23:57:24
Post #7





Grupa: Zarejestrowani
Postów: 4 655
Pomógł: 556
Dołączył: 17.03.2009
Skąd: Katowice

Ostrzeżenie: (0%)
-----


A czemu w ogóle chcesz nadpisywać?


--------------------
Zainteresowania: C#, PHP, JS, SQL, AJAX, XML, C dla AVR
Chętnie pomogę, lecz zanim napiszesz: Wujek Google , Manual PHP
Go to the top of the page
+Quote Post
markonix
post 2.04.2012, 00:55:54
Post #8





Grupa: Zarejestrowani
Postów: 2 707
Pomógł: 290
Dołączył: 16.12.2008
Skąd: Śląsk

Ostrzeżenie: (0%)
-----


Wyjaśniłem w drugiej części pierwszego postu.


--------------------
Go to the top of the page
+Quote Post
#luq
post 2.04.2012, 07:10:21
Post #9





Grupa: Zarejestrowani
Postów: 589
Pomógł: 91
Dołączył: 22.05.2008
Skąd: Gliwice

Ostrzeżenie: (0%)
-----


W widoku nadpisać POST... Hm... jak już to złe miejsce na takie rzeczy.
Po 2, przekazuj tablic a nie działaj na gołej zmiennej superglobalnej w klasie, kiedyś będziesz chciał coś zmienić na GET, będziesz musiał zmieniać wszystkie wystąpienia POST, nawet w prostym IDE to nie problem ale jak dla mnie tak się robić po prostu nie powinno.

  1. $ret = Forms::valid($_POST, array(
  2. 'foo' => 1, // lista defaultowych zmiennych
  3. 'bar' => 2
  4. ));
  5. $this->view->assign('formValues', $ret);


Ten post edytował #luq 2.04.2012, 07:16:14


--------------------
Moja gra - scraby.io
Go to the top of the page
+Quote Post
markonix
post 2.04.2012, 09:13:30
Post #10





Grupa: Zarejestrowani
Postów: 2 707
Pomógł: 290
Dołączył: 16.12.2008
Skąd: Śląsk

Ostrzeżenie: (0%)
-----


W żadnym wypadku nie chciałem tego robić w widoku.
Często mniej jednak kusi aby to zrobić z kontrolerze (zapytanie SQL).

Przyglądam się Twojego przykładowi i chyba rozumiem.
Metoda valid zwraca dane z POST, a w przypadku ich braku (nie wysłany formularz) dane defaultowe.
Potem w widoku w inputach <?= $formValues['name']; ?>.
W sumie to od początku było to moją alternatywną opcją tylko po prostu:
  1. <?php
  2. if (!isset($_POST['submit']))
  3. $ret = array('pole' => 'wartosc_domyslna');
  4. else
  5. $res = $_POST;
  6. // $res do widoku.


Ten post edytował markonix 2.04.2012, 09:14:35


--------------------
Go to the top of the page
+Quote Post
Pilsener
post 2.04.2012, 09:21:12
Post #11





Grupa: Zarejestrowani
Postów: 1 590
Pomógł: 185
Dołączył: 19.04.2006
Skąd: Gdańsk

Ostrzeżenie: (0%)
-----


Normalną praktyką jest używanie requesta, który zawiera żądania POST, GET, zmienne serwerowe itp. itd. etc.
Dostęp do tego w kontrolerze np. taki:
  1. $request = $this->getRequest();


Teraz możesz zmienną nadpisać/ustawić używając np. metody setParam. Jest to na pewno wygodniejsze niż korzystanie z "gołych" superglobalnych tablic.
Go to the top of the page
+Quote Post
markonix
post 2.04.2012, 16:42:33
Post #12





Grupa: Zarejestrowani
Postów: 2 707
Pomógł: 290
Dołączył: 16.12.2008
Skąd: Śląsk

Ostrzeżenie: (0%)
-----


Cytat(Pilsener @ 2.04.2012, 10:21:12 ) *
Normalną praktyką jest używanie requesta, który zawiera żądania POST, GET, zmienne serwerowe itp. itd. etc.

Ma to jakieś zalety ale czy to jest bezpieczne?
Jak dobrze rozumiem z kilku tablic generowana jest jedna.
Co jeżeli w POST i GET i mamy taki sam indeks?
Co gorsza tablicą SERVER możemy manipulować przez GET np. http_referer=XYZ.


--------------------
Go to the top of the page
+Quote Post
Pilsener
post 3.04.2012, 08:41:26
Post #13





Grupa: Zarejestrowani
Postów: 1 590
Pomógł: 185
Dołączył: 19.04.2006
Skąd: Gdańsk

Ostrzeżenie: (0%)
-----


Kwestia ustalenia ważności, np. post nadpisuje get ale już nie server, nie widzę też problemu by wyłączyć możliwość nadpisywania niekórych zmiennych nawet z wewnątrz kontrolera przy użyciu ->setParam, można też zmienne grupować albo inaczej obsługiwać nadpisywanie zmiennych.

Dodatkowo taki obiekt request wyposażamy w inne przydatne metody typu ->isPost czy np. sprawdzenie czy żądanie jest wysyłane ajaxem.

Wygodne to bo grupuje nam zmienne superglobalne i powiązane z nimi metody w jednym miejscu - a jak to okodujemy w szczegółach to już zależy od nas.
Go to the top of the page
+Quote Post
markonix
post 3.04.2012, 20:40:44
Post #14





Grupa: Zarejestrowani
Postów: 2 707
Pomógł: 290
Dołączył: 16.12.2008
Skąd: Śląsk

Ostrzeżenie: (0%)
-----


A miałoby sens set/get Param z drugim argumentem, który np. byłby defaultowo 'POST' i określałby do której tablicy się odwołujemy?

isPost to po prostu alias dla if($_POST) czy coś głębszego?


--------------------
Go to the top of the page
+Quote Post
Pilsener
post 3.04.2012, 22:05:46
Post #15





Grupa: Zarejestrowani
Postów: 1 590
Pomógł: 185
Dołączył: 19.04.2006
Skąd: Gdańsk

Ostrzeżenie: (0%)
-----


Z tego co wiem isPost() sprawdza po prostu, czy została wysłana tablica post i zwraca true albo false.

W np. Zend Frameworku drugi parametr to defaultowa wartość zmiennej, coś w stylu:
  1. $variable = $request->getParam('name','Zdzichu'); //jak nie przekazaliśmy nigdzie zmiennej "name" to domyślnie będzie to "Zdzichu" ;)


Natomiast ja to widzę bardziej tak:
  1. $name = $request->getPost()->name;
  2. $name = $request->getPost()->getParam('name');


Zależy, jak okodujemy.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 27.05.2024 - 03:03