znaczacy > comp.lang.* > comp.lang.php

Marek S (01.12.2018, 00:17)
Witam Was,

Mam klopot z ogarnieciem frameworka. Mamy fasade Request::get lub
Request::post. Chcialbym dowiedziec sie jaki kod fizycznie sie wykonuje
w tym momencie. Wymieklem w chwili gdy okazalo sie, ze get i post to
elementy tablicy - cholera wie gdzie inicjowanej. Czy ktos z Was potrafi
mi wyjasnic, gdzie znajduje sie kod kryjacy sie za fasadami? Pytam
ogólnie - niekoniecznie odnosnie quasi metod get i post Request'a.
Borys Pogorelo (01.12.2018, 21:35)
Dnia Fri, 30 Nov 2018 23:17:30 +0100, Marek S napisal(a):

> Mam klopot z ogarnieciem frameworka. Mamy fasade Request::get lub
> Request::post. Chcialbym dowiedziec sie jaki kod fizycznie sie wykonuje
> w tym momencie. Wymieklem w chwili gdy okazalo sie, ze get i post to
> elementy tablicy - cholera wie gdzie inicjowanej. Czy ktos z Was potrafi
> mi wyjasnic, gdzie znajduje sie kod kryjacy sie za fasadami? Pytam
> ogólnie - niekoniecznie odnosnie quasi metod get i post Request'a.


Fasada to tylko inny sposób dostepu do kontenera IoC. Czyli np. piszac
DB::query() siegasz do kontenera pod klucz zdefiniowany w pliku
Illuminate/Support/Facades/DB.php:

protected static function getFacadeAccessor()
{
return 'db';

}

co w efekcie jest równowazne:

app()->make('db')->query(...)

Zas do GET/POST najprosciej sie dostac przez instancje obiektu klasy
Request automatycznie wstrzykiwana przez podpowiadanie typów do metody
kontrolera obslugujacego biezaca akcje, czyli po prostu:

public function twojaAkcja(Request $request)
{
$zmiennaGet = $request->input('zmienna');
// ...
}

Oczywiscie mozesz tez pisac Request::input() lub request()->input() czy po
prostu app()->make('request')->input() albo nawet
app()->make(\Illuminate\Http\Request::class)->input().
Marek S (02.12.2018, 23:51)
W dniu 2018-12-01 o 20:35, Borys Pogorelo pisze:

> Fasada to tylko inny sposób dostepu do kontenera IoC. Czyli np. piszac
> DB::query() siegasz do kontenera pod klucz zdefiniowany w pliku
> Illuminate/Support/Facades/DB.php:


To ja wiem. Sek w tym, ze w Laravelu fasady sa w zasadzie puste. Cos je
uzupelnia po uruchomieniu frameworka. Tak jest w przypadku wspomnianego
Requesta. Fasada zawiera inicjalnie pusta tablice, która wypelnia nie
wiadomo co. Gdy wolamy get(), to wywoluje sie de facto odwolanie do
wewnetrznej tablicy z polem "get", które z kolei zawiera wskaznik do
jakiejs metody. Z pewnoscia nia nie jest Request::get bo ... Request nie
zawiera niczego takiego. Zreszta, który Request, bo znalazlem ich wiecej
niz 1?

Szukam konkretnie listingu metody get/post. Wymieklem analizujac sciezke
do sciezki zawierajaca sciezke.

> Zas do GET/POST najprosciej sie dostac przez instancje obiektu klasy
> Request automatycznie wstrzykiwana przez podpowiadanie typów do metody
> kontrolera obslugujacego biezaca akcje, czyli po prostu:
> public function twojaAkcja(Request $request)
> {
> $zmiennaGet = $request->input('zmienna');
> // ...
> }


Zupelnie nie o to mi chodzilo lecz o zródlo w/w metody.

A skoro wspominasz o tym, to równiez nie bardzo ogarniam takie
wstrzykiwanie. W/g mnie wstrzykiwaniem nazywa sie proces w postaci:

$obiekt1=new CosTam();
$obiekt2->metoda($obiekt1);

gdzie

class Obiekt2 {
...

//$_cosTam to cos, co wstrzykujemy
public function metoda(CosTam $_cosTam) {

}
}

Tymczasem odwrotne podejscie w postaci

$obiekt2->metoda(Co $co, Nam $nam, Slina $slina, Na $na, Jezyk $jezyk,
Przyniesie $przyniesie);

jest dla mnie równiez kompletnie niezrozumiale. Sadzilem, ze jakakolwiek
metoda gdziekolwiek powinna spodziewac sie scisle konkretnych
argumentów. Tymczasem okazuje sie, ze z jakis niejasnych wzgledów zadziala:

$obiekt->twojaAkcja(Request $request)

jak i

$obiekt->twojaAkcja(URL $url)

Czyli wynika z tego, ze w jakis magiczny sposób powyzszy $request bedzie
przekazywal wartosc new Request mimo iz nigdzie nie uzywam operatora
new. Tak PHP nie dziala. Operator new sam sie nie doda a mimo wszystko
to dziala. O co chodzi?
Borys Pogorelo (03.12.2018, 15:01)
Dnia Sun, 2 Dec 2018 22:51:27 +0100, Marek S napisal(a):

>> Fasada to tylko inny sposób dostepu do kontenera IoC. Czyli np. piszac
>> DB::query() siegasz do kontenera pod klucz zdefiniowany w pliku
>> Illuminate/Support/Facades/DB.php:

> To ja wiem. Sek w tym, ze w Laravelu fasady sa w zasadzie puste. Cos je
> uzupelnia po uruchomieniu frameworka.


Przeczytaj jeszcze raz dokladnie to co napisalem. Masz metode
getFacadeAccessor(), która zwraca alias po którym obiekt jest pobierany z
kontenera IoC.

Jesli chcesz znalezc to "cos", to jest ono w metodzie
Illuminate\Foundation\Application::registerCoreCon tainerAliases()

> jest dla mnie równiez kompletnie niezrozumiale. Sadzilem, ze jakakolwiek
> metoda gdziekolwiek powinna spodziewac sie scisle konkretnych
> argumentów. Tymczasem okazuje sie, ze z jakis niejasnych wzgledów zadziala:


Jesli przeczytasz dokumentacje i opis "type hinting", to wszystko bedzie
jasne. Laravel uzywa Reflection by automatycznie podstawic obiekty z IoC na
podstawie typów. Taka magia, calkiem wygodna.
Marek S (04.12.2018, 21:55)
Hej,

Odpowiem niebawem - mam ograniczony czas. Temat jest wazny dla mnie.
Rafal Podsiadly (05.12.2018, 22:41)
@Marku czytales ?
Marek S (06.12.2018, 23:43)
W dniu 2018-12-05 o 21:41, Rafal Podsiadly pisze:

> @Marku czytales ?


Tak, oczywiscie. Napisalem, ze poleglem analizujac realny kod. Dotarlem
do etapu kiedy fasada nie robi nic innego jak tylko zwraca string.
Bazujac na przykladzie z dokumentacji jest to:

protected static function getFacadeAccessor() { return 'cache'; }

Ale string przeciez nie wykona zadnej operacji cache'owania wiec
funkcjonalnosc z Cache::get() z pewnoscia niczego tu nie wykona.

No to lecimy dalej. Ten string wedruje do Service Container'a. A co on
takiego robi? Zaglada do pokrótce tablicy (UserRepository) i wywoluje
find. Czyli znów tu kodu naszego Cache::get() nie znajdziemy.

Znów lecmy dalej. W tablicy models znajduje sie wreszcie obiekt
reprezentujacy wolana metode. Fajnie, ale tablica obiektów nie ma nic
wspólnego z kodem zródlowym klas tych obiektów. Wiec znów jestesmy w
czarnej d... Ale przynajmniej wiemy czego szukac.

Teraz trzeba zajrzec od drugiej strony i znalezc miejsce, w którym ta
tablica bedzie wypelniana obiektami. Zapewne bedzie trzeba rozpoczac
poszukiwania od index.php i schodzic coraz nizej.

W ten sposób caly wieczór bede szukal zródel Cache::get albo Route::get
itd. Czytanie dokumentacji zero pomoglo. To jest tylko ogólnikowe bla
bla bla. Do programowania wystarczy ale nie pozwoli na wgryzienie sie w
zródlo. Wiec ponawiam pytanie z watku otwierajacego.
Rafal Podsiadly (07.12.2018, 07:50)


Klase mozna uyworzyc przechowujac jej nazwe w zmiennej. Czyli w efekcie return cache odwoluje sie do klasy cache ktora jest tworzona w momencie wywolania.

Z tego co wyczytalem w php.net ten mechanizm jest przestarzaly i nie powinno sie go uzywac.
Wojciech Bancer (07.12.2018, 10:24)
On 2018-12-07, Rafal Podsiadly <spinacz24> wrote:
>
> Klase mozna uyworzyc przechowujac jej nazwe w zmiennej. Czyli w efekcie return cache odwołuje sie do klasy cache ktora jest tworzona w momencie wywolania.
> Z tego co wyczytalem w php.net ten mechanizm jest przestarzaly i nie powinno sie go uzywac.


Po prostu lepiej do tego użyć ReflectionClass.

$class = new \ReflectionClass('Klasa');
$instance = $class->newInstance();
Marek S (08.12.2018, 01:01)
W dniu 2018-12-07 o 06:50, Rafal Podsiadly pisze:
>
> Klase mozna uyworzyc przechowujac jej nazwe w zmiennej. Czyli w efekcie return cache odwoluje sie do klasy cache ktora jest tworzona w momencie wywolania.


Ok, ale zupelnie nie o to mi chodzilo w zapytaniu. Wydawalo mi sie iz
pytanie jest klarowne. Pytalem sie o to gdzie jest kod dla akcji
Request::get lub jakiejkolwiek innej. Nie interesuje mnie fasada, która
nic nie robi poza zajmowaniem czasu CPU lecz fizyczny kod PHP.

Nie wiem w czym rzecz, ze nie jestem zrozumialy w zapytaniu. Juz dwie
osoby skierowaly mnie do zapoznania sie z dzialaniem fasad w Laravelu
zamiast do metodologii docierania do zródel tego co fizycznie metoda X
czy Y realizuje.
Rafal Podsiadly (08.12.2018, 10:23)
Zwracaja uwage na to co napisal @Borys zagladam sobie da katalogu

vendor\laravel\framework\src\Illuminate\Routing

I tam mam kod dla calego routingu.

vendor\laravel\framework\src\Illuminate\Routing\Ro ute.php#894

Mam twój route::get

W korzystaniu z frameroków chodzi o to, ze by nie zastanawiac sie jak to dziala a zaufac i pisac kod. separowac to co jest powtarzalne dla wielu projektów do jednego miejsca i o tym zapomniec

Dlatego wspomiania fasada route jest zarejestowana w pliku
config\app.php#221

Nastepnie uruchomianie fasady generuje kod wyzwolenia vendor\laravel\framework\src\Illuminate\Routing\Ro ute.php i to zawsze sie do tego obiektu odwolujesz.

Dzieki takiemu zachowaniu mamy leniwe ladowanie (czyli tylko wtedy gdy zapytam) i oszczedzamy na miejscu bo ladujemy tylko to o copytam.

Dzieki temu inny jest zestaw metod (patrz w anotate) dla projektu uruchamianego z konsoli by go przetestowac
a inny zestaw metod dla projektu z http
Marek S (08.12.2018, 20:29)
W dniu 2018-12-08 o 09:23, Rafal Podsiadly pisze:
> Zwracaja uwage na to co napisal @Borys zagladam sobie da katalogu
> vendor\laravel\framework\src\Illuminate\Routing
> I tam mam kod dla calego routingu.
> vendor\laravel\framework\src\Illuminate\Routing\Ro ute.php#894
> Mam twój route::get


A czy zagladales w ogóle do kodu? Tam nie ma metody get(). W najnowszej
wersji Laravela mam cos takiego:

public function __get($key)
{
return $this->parameter($key);
}

__get() to zupelnie cos innego niz get(). Jest to przeciez magiczna
funkcja wywolywana gdy próbujemy odczytac nieistniejacy komponent klasy,
co tez wlasnie czynimy posrednio za pomoca Route::get(). Oczywiscie
doszedlem do tego przekopujac sie przez zasieki frameworka.

W tejze metodzie znajduje sie kolejne posredniczace ogniwo lancuszka
swietego Antoniego. __get wywoluje metode parameter($key). Ta z kolei
korzysta z metody statycznej Arr:get, która znów cos tam robi zupelnie
nie zwiazanego z moim pytaniem.

Wykonuje sie w efekcie pierdylion róznych funkcji zawierajacych po
linijce kodu zanim wreszcie dotrzemy do wlasciwego obiektu. A poza tym,
przypomne - nie obiekt mnie interesuje lecz jego kod zródlowy.

> W korzystaniu z frameroków chodzi o to, ze by nie zastanawiac sie jak
> to dziala a zaufac i pisac kod. separowac to co jest powtarzalne dla
> wielu projektów do jednego miejsca i o tym zapomniec


Alez oczywiscie masz racje, ale ja nie o to pytam. Napisalem zreszta w
poprzedniej wypowiedzi, ze "do programowania ta wiedza wystarczy" ale ja
nie pytam sie o to jak programowac lecz o fizyczny kod np. Route::get.
De facto pytam o metodologie docierania do kodu zródlowego kazdego
elementu frameworka.

> Dlatego wspomiania fasada route jest zarejestowana w pliku
> config\app.php#221


Ok, to rozumiem.

> Nastepnie uruchomianie fasady generuje kod wyzwolenia
> vendor\laravel\framework\src\Illuminate\Routing\Ro ute.php i to zawsze
> sie do tego obiektu odwolujesz.


To tez rozumiem.

> Dzieki takiemu zachowaniu mamy leniwe ladowanie (czyli tylko wtedy
> gdy zapytam) i oszczedzamy na miejscu bo ladujemy tylko to o co
> pytam.


I to jest fajne - ale nie ma zwiazku z pytaniem. Choc tu tez korci mnie
zapytac o zupelnie cos innego, ale obawiam sie, ze wtedy dyskusja na tym
sie skupi i umknie moje pierwotne pytanie :-
Wojciech Bancer (08.12.2018, 21:27)
On 2018-12-08, Marek S <precz> wrote:

[...]

> Ależ oczywiście masz rację, ale ja nie o to pytam. Napisałem zresztą w
> poprzedniej wypowiedzi, że "do programowania ta wiedza wystarczy" ale ja
> nie pytam się o to jak programować lecz o fizyczny kod np. Route::get.
> De facto pytam o metodologię docierania do kodu źródłowego każdego
> elementu frameworka.


No najwięcej szans masz z dobrym edytorem, który ma dobre podpowiadanie.
PhpStorm chyba ma taki plugin.
Jeśli działa tak jak symfony, to jest szansa że dość dużo podpowie (ja niestety laravela
nie używam), a jak będzie znał metodę, to i będziesz mógł do jej definicji trafić.
Wszystkiego Ci nie podpowie, bo na 90% obiekty są zbierane z różnych komponentów,
traitów, metod magicznych i co tam jeszcze.
Marek S (08.12.2018, 22:53)
W dniu 2018-12-08 o 20:27, Wojciech Bancer pisze:

> No najwięcej szans masz z dobrym edytorem, który ma dobre podpowiadanie.
> PhpStorm chyba ma taki plugin.


Pracuję w tym właśnie edytorze i mam w/w plugin. On jest niewiele wart w
powyższej kwestii. Rozwiązuje natomiast istotny problem. Ponieważ metody
udostępniane przez Laravel są ściśle tajne (dla IDE), to plugin
doinstalowuje niby fałszywą implementację tych metod (na poziomie
helpera). Dzięki temu mam podpowiedzi parametrów itp. Dodatkowo w menu
frameworków można sobie wtedy coś poustawiać dla Laravela. W żadnym
razie nie uzyskasz informacji na temat źródła fl Route::get()

> Jeśli działa tak jak symfony, to jest szansa że dość dużo podpowie (ja niestety laravela
> nie używam), a jak będzie znał metodę, to i będziesz mógł do jej definicji trafić.
> Wszystkiego Ci nie podpowie, bo na 90% obiekty są zbierane z różnych komponentów,
> traitów, metod magicznych i co tam jeszcze.


No więc właśnie. PHPStorm to zwykłe IDE. Jeśli producent frameworka
zaszyfrował i założył zasieki na wścibskich, to jedyne co otrzymujesz,
to podpowiedzi do interfejsu w trakcie programowania.
Marek S (08.12.2018, 23:03)
W dniu 2018-12-08 o 09:23, Rafal Podsiadly pisze:

> W korzystaniu z frameroków chodzi o to, ze by nie zastanawiac sie jak to dziala a zaufac i pisac kod. separowac to co jest powtarzalne dla wielu projektów do jednego miejsca i o tym zapomniec


Tak naszla mnie wlasnie mysl a'propos powyzszego. Od czasu do czasu
zarabiam na zleceniach pt. dzialalo cos w jQuery (które tez jest
frameworkiem) a przestalo bo wyszly np. nowsze przegladarki. Zaufanie
wiec nalezy miec mocno ograniczone. Co ja wtedy robie? Zastepuje
niedzialajaca jedna linijke kodu jQuery jedna linijka kodu JS i nie
wnikam dlaczego cos przestalo dzialac bo ktos kiedys zaufal
frameworkowi. Przypuszczam, ze dlatego mam prace bo dociekam, slepo
niczemu nie ufam i rozwiazuje fuckupy od reki.

Podobne wątki