Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Symfony 4 - jaka korzyść z wstrzykiwanych service providerów?
49 views
Skip to first unread message
Marek S
Apr 14, 2019, 4:27:53 PM4/14/19
to
Witam,
Wyjaśnię, że stawiam pierwsze kroki w Symfony 4. Dotarłem do etapu
tworzenia Service Providerów w jakimś kursie. Oczywiście ja, jakto ja,
nigdy bezmyśnie nie przepisuję tego, co w kursie mówią lecz od razu
buduję życiowe sytuacje symulując praktyczne użycie.
No i albo czegoś nie ogarniam, albo autowiring to jakaś ściema i kula u
nogi, czasem nawet uniemożliwiająca korzystanie z tej funkcjonalności.
Korzystanie z klas w klasyczny sposób dla PHP wydaje się być
nieporównywalnie lepszym podejściem. Sprostujcie mnie. Zapewne czegoś
nie dostrzegam.
Oto przykład kontrolera, gdzie poległem:
<?php
namespace App\Controller;
use App\Entity\Users;
use App\Services\MarekService;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Routing\Annotation\Route;
class DefaultController extends AbstractController {
/**
* DefaultController constructor.
*/
public function __construct(MarekService $marekService) {
array_unshift($marekService->gifts, "constr");
}
private function getRandom(MarekService $marekService): array {
return $marekService->gifts;
}
/**
* @Route("/default", name="default")
*/
public function index(MarekService $marekService) {
$users =
$this->getDoctrine()->getRepository(Users::class)->findBy([], ['name' =>
'ASC']);
return $this->render('default/index.html.twig', [
'controller_name' => 'DefaultController',
"users" => $users,
"gifts2" => $this->getRandom(),
"gifts" => $marekService->gifts,
]);
}
}
Załóżmy, że wszystkie metody będą potrzebowały korzystać z MarekService.
Jeśli chodzi o metody publiczne, te, które budują routing lub
konstruktor, to wszystko ok choć, moim zdaniem, niepotrzebnie dużo
piszemy przekazując do każdej z tych metod regułkę:
MarekService $marekService
Prościej byłoby w konstruktorze przypisać do zmiennej prywatnej:
$this->prv=new MarekService();
...i dalej w kodzie posługiwać się $this->priv zamiast każdorazowo
wstrzykiwać coś.
Po drugie, przy wstrzykiwaniu powstała sprzeczność. Popatrzcie na metodę
prywatną $this->getRandom(). Wstrzykuję do niej MarekService, a z
drugiej strony chcę ją użyć bez przekazywania parametrów (na dole
skryptu), bo nie ma po co ich przekazywać. Metoda ma mi coś zwrócić i
koniec, kropka. Gdybym bazował na $this->priv, to taka sprzeczność nie
miałaby miejsca.
--
Pozdrawiam,
Marek
Wyjaśnię, że stawiam pierwsze kroki w Symfony 4. Dotarłem do etapu
tworzenia Service Providerów w jakimś kursie. Oczywiście ja, jakto ja,
nigdy bezmyśnie nie przepisuję tego, co w kursie mówią lecz od razu
buduję życiowe sytuacje symulując praktyczne użycie.
No i albo czegoś nie ogarniam, albo autowiring to jakaś ściema i kula u
nogi, czasem nawet uniemożliwiająca korzystanie z tej funkcjonalności.
Korzystanie z klas w klasyczny sposób dla PHP wydaje się być
nieporównywalnie lepszym podejściem. Sprostujcie mnie. Zapewne czegoś
nie dostrzegam.
Oto przykład kontrolera, gdzie poległem:
<?php
namespace App\Controller;
use App\Entity\Users;
use App\Services\MarekService;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Routing\Annotation\Route;
class DefaultController extends AbstractController {
/**
* DefaultController constructor.
*/
public function __construct(MarekService $marekService) {
array_unshift($marekService->gifts, "constr");
}
private function getRandom(MarekService $marekService): array {
return $marekService->gifts;
}
/**
* @Route("/default", name="default")
*/
public function index(MarekService $marekService) {
$users =
$this->getDoctrine()->getRepository(Users::class)->findBy([], ['name' =>
'ASC']);
return $this->render('default/index.html.twig', [
'controller_name' => 'DefaultController',
"users" => $users,
"gifts2" => $this->getRandom(),
"gifts" => $marekService->gifts,
]);
}
}
Załóżmy, że wszystkie metody będą potrzebowały korzystać z MarekService.
Jeśli chodzi o metody publiczne, te, które budują routing lub
konstruktor, to wszystko ok choć, moim zdaniem, niepotrzebnie dużo
piszemy przekazując do każdej z tych metod regułkę:
MarekService $marekService
Prościej byłoby w konstruktorze przypisać do zmiennej prywatnej:
$this->prv=new MarekService();
...i dalej w kodzie posługiwać się $this->priv zamiast każdorazowo
wstrzykiwać coś.
Po drugie, przy wstrzykiwaniu powstała sprzeczność. Popatrzcie na metodę
prywatną $this->getRandom(). Wstrzykuję do niej MarekService, a z
drugiej strony chcę ją użyć bez przekazywania parametrów (na dole
skryptu), bo nie ma po co ich przekazywać. Metoda ma mi coś zwrócić i
koniec, kropka. Gdybym bazował na $this->priv, to taka sprzeczność nie
miałaby miejsca.
--
Pozdrawiam,
Marek
Borys Pogoreło
Apr 14, 2019, 6:56:40 PM4/14/19
to
Dnia Sun, 14 Apr 2019 22:27:45 +0200, Marek S napisał(a):
> Prościej byłoby w konstruktorze przypisać do zmiennej prywatnej:
>
> $this->prv=new MarekService();
>
> ...i dalej w kodzie posługiwać się $this->priv zamiast każdorazowo
> wstrzykiwać coś.
Autowiring ma za zadanie dostarczyć Ci gotowy obiekt. Jeśli potrzebujesz go
> Prościej byłoby w konstruktorze przypisać do zmiennej prywatnej:
>
> $this->prv=new MarekService();
>
> ...i dalej w kodzie posługiwać się $this->priv zamiast każdorazowo
> wstrzykiwać coś.
w wielu miejscach, to rzecz jasna najwięcej sensu ma wstrzyknięcie go w
konstruktorze.
Z kolei powyższy przykład nie ma sensu - jeśli potrzebujesz nowy obiekt, to
go utwórz, do tego autowiring nie jest potrzebny.
> Po drugie, przy wstrzykiwaniu powstała sprzeczność. Popatrzcie na metodę
> prywatną $this->getRandom(). Wstrzykuję do niej MarekService, a z
> drugiej strony chcę ją użyć bez przekazywania parametrów (na dole
> skryptu), bo nie ma po co ich przekazywać. Metoda ma mi coś zwrócić i
> koniec, kropka. Gdybym bazował na $this->priv, to taka sprzeczność nie
> miałaby miejsca.
Najpierw określ, co ta metoda (i usługa jako taka) ma w ogóle robić, bo na
razie zwraca tablicę?/kolekcję? gifts bez żadnych zmian. A MarekService to
już w ogóle z niczym się nie kojarzy - ale to jak rozumiem po prostu testy.
--
Borys Pogoreło
borys(#)leszno,edu,pl
Marek S
Apr 15, 2019, 5:38:36 PM4/15/19
to
W dniu 2019-04-15 o 00:56, Borys Pogoreło pisze:
>> Prościej byłoby w konstruktorze przypisać do zmiennej prywatnej:
>>
>> $this->prv=new MarekService();
>>
>> ...i dalej w kodzie posługiwać się $this->priv zamiast każdorazowo
>> wstrzykiwać coś.
>
> Autowiring ma za zadanie dostarczyć Ci gotowy obiekt.
Czy operator new nie tworzy właśnie gotowego obiektu?
Przedebugowałem kod i wyszło mi, że pierwsze wstrzyknięcie jest
równoważnikiem wywołania new. Kolejne: to już korzystanie z tego obiektu.
> Jeśli potrzebujesz go
> w wielu miejscach, to rzecz jasna najwięcej sensu ma wstrzyknięcie go w
> konstruktorze.
Tak też myślałem. Tutoriale czasem powodują moje zakłopotanie. W Udemy
gość pokazuje wstrzykiwanie w wielu metodach kontrolera. Wydało mi się
to ... wręcz patologiczne. Pewnie jeszcze wrócę tu na grupę z podobnymi
doświadczeniami do wyprostowania - więc z góry dziękuję za wyrozumiałość.
>
> Z kolei powyższy przykład nie ma sensu - jeśli potrzebujesz nowy obiekt, to
> go utwórz, do tego autowiring nie jest potrzebny.
Dziś dyskutowałem z kolegą na ten sam temat. Zwrócił mi uwagę na pewną
cechę Symfony. Można w niej zwyczajnie osadzać w twigach dowolną ilość
kontrolerów i wskazywać na metody jakie mają renderować dany fragment.
Tak na marginesie w Laravelu to było niby też możliwe ale i tak bardzo
ograniczone funkcjonalnie - m.in. dlatego pożegnałem ten framework.
Może się zdarzyć, że niektóre kontrolery będą potrzebowały MarekService.
Wtedy używając wstrzyknięcia w konstruktorach (a nie new) powodujemy,
że serwis zostanie zainicjowany raz, przez pierwszy w kolejności
kontroler, a reszta kontrolerów będzie korzystała z instancji serwisu.
> Po pierwsze to ta metoda ma wyjątkowo nieczytelną nazwę. getRandom...co?
:-D :-D Ok. Następnym razem nazwę ją dupa(). Serio! :-D Wtedy nikt nie
śmie zapytać do czego dupa służy :-D Taki dialekt paru moich znajomych z
powodzeniem stosuje (ja również) jako odpowiednik Lorem ipsum w tekstach
pisanych :-D
> Najpierw określ, co ta metoda (i usługa jako taka) ma w ogóle robić, bo na
> razie zwraca tablicę?/kolekcję?
A różnie. W ramach testów zmieniam do woli jej funkcjonalność.
Pierwotnie była to tablica, a teraz kolekcja ORM. Jutro być może będzie
coś innego :-D
> gifts bez żadnych zmian. A MarekService to
> już w ogóle z niczym się nie kojarzy - ale to jak rozumiem po prostu testy.
>
Dokładnie tak :-D Wszystko co robię z Symfonią, wielokrotnie trafiało do
kosza i inicjowałem nowe struktury w celach poznawczych. I jeszcze przez
jakiś czas tab będzie, dopóki nie poznam środowiska by się w nim
sprawnie poruszać.
P.S.
W międzyczasie wynikła pewna niedogodność dla mnie. W odróżnieniu od
Laravela, czystego PHP, JS, CSS, HTML, cokolwiek - nie potrafię poruszać
się po dokumentacji Symfony. Przykładowo, w wielu przykładach
kontrolerów widuję $this->addFlash(). Z jakiegoś komentarza w kodzie
dowiedziałem się, że jest to odpowiednik:
$request->getSession()->getFlashBag()->add()
Załóżmy jednak, że czyjś komentarz mi nie wystarcza i chciałbym w
oficjalnej dokumentacji poczytać o tym. Jak docierasz do takich
informacji? Masz jakąś listę linków? Dlaczego ta funkcja wydaje się być
nieudokumentowaną, choć jest powszechnie używana?
W tym względzie dałbym jako adept, mega wielki minus...
--
Pozdrawiam,
Marek
>> Prościej byłoby w konstruktorze przypisać do zmiennej prywatnej:
>>
>> $this->prv=new MarekService();
>>
>> ...i dalej w kodzie posługiwać się $this->priv zamiast każdorazowo
>> wstrzykiwać coś.
>
> Autowiring ma za zadanie dostarczyć Ci gotowy obiekt.
Przedebugowałem kod i wyszło mi, że pierwsze wstrzyknięcie jest
równoważnikiem wywołania new. Kolejne: to już korzystanie z tego obiektu.
> Jeśli potrzebujesz go
> w wielu miejscach, to rzecz jasna najwięcej sensu ma wstrzyknięcie go w
> konstruktorze.
gość pokazuje wstrzykiwanie w wielu metodach kontrolera. Wydało mi się
to ... wręcz patologiczne. Pewnie jeszcze wrócę tu na grupę z podobnymi
doświadczeniami do wyprostowania - więc z góry dziękuję za wyrozumiałość.
>
> Z kolei powyższy przykład nie ma sensu - jeśli potrzebujesz nowy obiekt, to
> go utwórz, do tego autowiring nie jest potrzebny.
cechę Symfony. Można w niej zwyczajnie osadzać w twigach dowolną ilość
kontrolerów i wskazywać na metody jakie mają renderować dany fragment.
Tak na marginesie w Laravelu to było niby też możliwe ale i tak bardzo
ograniczone funkcjonalnie - m.in. dlatego pożegnałem ten framework.
Może się zdarzyć, że niektóre kontrolery będą potrzebowały MarekService.
Wtedy używając wstrzyknięcia w konstruktorach (a nie new) powodujemy,
że serwis zostanie zainicjowany raz, przez pierwszy w kolejności
kontroler, a reszta kontrolerów będzie korzystała z instancji serwisu.
> Po pierwsze to ta metoda ma wyjątkowo nieczytelną nazwę. getRandom...co?
śmie zapytać do czego dupa służy :-D Taki dialekt paru moich znajomych z
powodzeniem stosuje (ja również) jako odpowiednik Lorem ipsum w tekstach
pisanych :-D
> Najpierw określ, co ta metoda (i usługa jako taka) ma w ogóle robić, bo na
> razie zwraca tablicę?/kolekcję?
Pierwotnie była to tablica, a teraz kolekcja ORM. Jutro być może będzie
coś innego :-D
> gifts bez żadnych zmian. A MarekService to
> już w ogóle z niczym się nie kojarzy - ale to jak rozumiem po prostu testy.
>
kosza i inicjowałem nowe struktury w celach poznawczych. I jeszcze przez
jakiś czas tab będzie, dopóki nie poznam środowiska by się w nim
sprawnie poruszać.
P.S.
W międzyczasie wynikła pewna niedogodność dla mnie. W odróżnieniu od
Laravela, czystego PHP, JS, CSS, HTML, cokolwiek - nie potrafię poruszać
się po dokumentacji Symfony. Przykładowo, w wielu przykładach
kontrolerów widuję $this->addFlash(). Z jakiegoś komentarza w kodzie
dowiedziałem się, że jest to odpowiednik:
$request->getSession()->getFlashBag()->add()
Załóżmy jednak, że czyjś komentarz mi nie wystarcza i chciałbym w
oficjalnej dokumentacji poczytać o tym. Jak docierasz do takich
informacji? Masz jakąś listę linków? Dlaczego ta funkcja wydaje się być
nieudokumentowaną, choć jest powszechnie używana?
W tym względzie dałbym jako adept, mega wielki minus...
--
Pozdrawiam,
Marek
Borys Pogoreło
Apr 16, 2019, 11:55:34 AM4/16/19
to
Dnia Mon, 15 Apr 2019 23:38:33 +0200, Marek S napisał(a):
> Czy operator new nie tworzy właśnie gotowego obiektu?
> Przedebugowałem kod i wyszło mi, że pierwsze wstrzyknięcie jest
> równoważnikiem wywołania new. Kolejne: to już korzystanie z tego obiektu.
W najprostszym przypadku tak właśnie jest. Ale zadaniem autowiringu nie
> Czy operator new nie tworzy właśnie gotowego obiektu?
> Przedebugowałem kod i wyszło mi, że pierwsze wstrzyknięcie jest
> równoważnikiem wywołania new. Kolejne: to już korzystanie z tego obiektu.
jest proste tworzenie obiektów, tylko wyciąganie ich z kontenera. Gdzie
najczęściej są już skonfigurowane.
Mam wrażenie, że kompletnie pominąłeś ten temat w Laravelu, choć było to
tłumaczone.
> Tak też myślałem. Tutoriale czasem powodują moje zakłopotanie. W Udemy
> gość pokazuje wstrzykiwanie w wielu metodach kontrolera. Wydało mi się
> to ... wręcz patologiczne. Pewnie jeszcze wrócę tu na grupę z podobnymi
> doświadczeniami do wyprostowania - więc z góry dziękuję za wyrozumiałość.
> Dziś dyskutowałem z kolegą na ten sam temat. Zwrócił mi uwagę na pewną
> cechę Symfony. Można w niej zwyczajnie osadzać w twigach dowolną ilość
> kontrolerów i wskazywać na metody jakie mają renderować dany fragment.
> Tak na marginesie w Laravelu to było niby też możliwe ale i tak bardzo
> ograniczone funkcjonalnie - m.in. dlatego pożegnałem ten framework.
to średni pomysł i szybka droga do bałaganu w kodzie, którego już nikt poza
autorem nie ogarnie.
>> Po pierwsze to ta metoda ma wyjątkowo nieczytelną nazwę. getRandom...co?
>
> :-D :-D Ok. Następnym razem nazwę ją dupa(). Serio! :-D Wtedy nikt nie
> śmie zapytać do czego dupa służy :-D Taki dialekt paru moich znajomych z
> powodzeniem stosuje (ja również) jako odpowiednik Lorem ipsum w tekstach
> pisanych :-D
testowym, który pokazujesz światu. Ale... chyba nie ma sensu.
> A różnie. W ramach testów zmieniam do woli jej funkcjonalność.
> Pierwotnie była to tablica, a teraz kolekcja ORM. Jutro być może będzie
> coś innego :-D
> P.S.
> W międzyczasie wynikła pewna niedogodność dla mnie. W odróżnieniu od
> Laravela, czystego PHP, JS, CSS, HTML, cokolwiek - nie potrafię poruszać
> się po dokumentacji Symfony. Przykładowo, w wielu przykładach
> kontrolerów widuję $this->addFlash(). Z jakiegoś komentarza w kodzie
> dowiedziałem się, że jest to odpowiednik:
>
> $request->getSession()->getFlashBag()->add()
>
> Załóżmy jednak, że czyjś komentarz mi nie wystarcza i chciałbym w
> oficjalnej dokumentacji poczytać o tym. Jak docierasz do takich
> informacji? Masz jakąś listę linków? Dlaczego ta funkcja wydaje się być
> nieudokumentowaną, choć jest powszechnie używana?
https://github.com/symfony/symfony/blob/4.0/src/Symfony/Bundle/FrameworkBundle/Templating/Helper/SessionHelper.php#L45
--
Borys Pogoreło
borys(#)leszno,edu,pl
Marek S
Apr 16, 2019, 6:11:41 PM4/16/19
to
W dniu 2019-04-16 o 17:55, Borys Pogoreło pisze:
>> Czy operator new nie tworzy właśnie gotowego obiektu?
>> Przedebugowałem kod i wyszło mi, że pierwsze wstrzyknięcie jest
>> równoważnikiem wywołania new. Kolejne: to już korzystanie z tego obiektu.
>
> W najprostszym przypadku tak właśnie jest. Ale zadaniem autowiringu nie
> jest proste tworzenie obiektów, tylko wyciąganie ich z kontenera. Gdzie
> najczęściej są już skonfigurowane.
No właśnie o tym piszę :-)
> Mam wrażenie, że kompletnie pominąłeś ten temat w Laravelu, choć było to
> tłumaczone.
Właśnie to jest ta chwila, o której wspominałem. W Laravelu nie byłem w
stanie ogarnąć ideologii. Czytałem niektóre rozdziały po 5x testując
równolegle kod. Nie mając w głowie całej tej ideologii, nie byłem w
stanie wyobrazić sobie aplikacji.
Zapoznając się z Symfonią mam wrażenie, że jest ona prosta jak pisanie w
czystym PHP. Bez bełkotu fasadowego, który czasem nawet jedną PHPową
funkcję zamykał w sobie, by ją pod inną nazwą udostępnić. A do tego nie
było szans na analizę źródeł gdy coś w dokumentacji nie było jasne bo
źródła w Laravelu to najczęściej 1-linijkowy kod, który zwykle woła inny
1-linijkowy kod a ten kolejny. Udało mi się w ten sposób prześledzić
kilkanaście poziomów zagnieżdżenia i niczego się nie dowiedzieć. Swoją
drogą jak potężny stos musi tworzyć aplikacja "hello world" w Laravelu,
to sobie nie jestem w stanie wyobrazić nawet. W Symfonii kod frameworka
może czasem za dokumentację robić.
Dlatego odniosłeś wrażenie, że pominąłem całą sekcję dokumentacji.
Chiński bym szybciej pojął.
>> Dziś dyskutowałem z kolegą na ten sam temat. Zwrócił mi uwagę na pewną
>> cechę Symfony. Można w niej zwyczajnie osadzać w twigach dowolną ilość
>> kontrolerów i wskazywać na metody jakie mają renderować dany fragment.
>> Tak na marginesie w Laravelu to było niby też możliwe ale i tak bardzo
>> ograniczone funkcjonalnie - m.in. dlatego pożegnałem ten framework.
>
> I bardzo dobrze, że tak było, bo rozrzucanie logiki po wielu kontrolerach
> to średni pomysł i szybka droga do bałaganu w kodzie, którego już nikt poza
> autorem nie ogarnie.
Nie rozumiem? W Symfonii udało mi się zrobić przeglądarkę newsów i jej
renderowanie za pomocą 1 kontrolera na stronie generowanej z udziałem
kilku innych kontrolerów. W Laravelu każdy podobny do w/w funkcjonalnie
kontroler musiał mieć brata bliźniaka w postaci serwisu, bo tylko
serwisy dawało się osadzać. Więc w laravelu jedna funkcjonalność była
rozwalona na przynajmniej 2 pliki. A w Symfonii masz tylko 1 przecież.
Nie wspominając o konieczności rozbijania jednej złożonej strony na
wiele blade'ów zamiast umieszczania prostych bloczków typu
render(controller + twig do niego). Wtedy twig podąża za kontrolerem
przenosząc taki bloczek w inne miejsce.
Właśnie to bałaganiarstwo Laravela też było gwoździem do trumny.
Oczywiście opisuję swoje wrażenia.
> Mógłbym zrobić Ci wykład z dbania o poprawne nazewnictwo w kodzie, również
> testowym, który pokazujesz światu. Ale... chyba nie ma sensu.
Ok, to może inaczej. Konkretnie. Robię jakąś funkcję, której zadaniem
będzie istnieć przez kilka minut - aż sprawdzę jak jakiś mechanizm
działa a potem ją skasuję.
Powiedz mi zatem, jak Ty dbasz o poprawne nazewnictwo w takich
przypadkach? Czy tworzysz sekcje autodokumentacji do takich metod?
Pchasz to na Gita? Opisujesz potem powody usunięcia tejże funkcji w
commitach? Czy tą czynność rejestrujesz np. w Sprintach na Scumie?
Tworzysz do niej backloga na Agile Acceleratorze i powołujesz się na ID
ticketu w commitach? Masz jakiegoś testera, któremu zlecasz testy kodu
pokroju "hello world"?
A czy gdy testujesz fragment kodu na np. PHP Sandboxie (taka strona
WWW), to również dbasz tam o takie rzeczy skoro po zamknięciu
przeglądarki kod i tak zniknie?
Serio?
Sorki, ale wydaje mi się paranoją dbanie o czystość chwilowego kodu.
Trzeba mieć naprawdę nadmiar wolnego czasu by tak postępować. Kod
którego nikt nigdy nie zobaczy bo zniknie po paru minutach egzystencji,
przy takim postępowaniu rozpościera się na dni pracy.
>> A różnie. W ramach testów zmieniam do woli jej funkcjonalność.
>> Pierwotnie była to tablica, a teraz kolekcja ORM. Jutro być może będzie
>> coś innego :-D
>
> I my mamy zgadywać?
Po co? Ale ... o co chodzi? Dlaczego potrzebujesz mieć ściśle
zdefiniowaną funkcjonalność tej metody? Załóżmy, że kosi trawnik.
Ona po prostu tam jest. Załóż, że nic nie zwraca a my chcemy ją tylko
wywołać z parametrem jakimś (np. wartość int). Tymczasem wstrzyknięcie
serwisu do metody blokuje możliwość przekazanie parametru do niej, bo
spodziewa się MarekService, a nie int'a.
> Bardzo prosto, zaglądasz do źródeł. getFlash() to jest helper:
>
> https://github.com/symfony/symfony/blob/4.0/src/Symfony/Bundle/FrameworkBundle/Templating/Helper/SessionHelper.php#L45
>
Ale tam też nie ma addFash(), o który pytam :-(
Zresztą nawet jeśli byłby tam on, to dowiadywanie się o istnieniu (w
dodatku powszechnie stosowanych) funkcji/metod poprzez analizę źródeł
zamiast szybkiego dowiedzenia się w dokumentacji, jest lekko dziwne...
--
Pozdrawiam,
Marek
>> Czy operator new nie tworzy właśnie gotowego obiektu?
>> Przedebugowałem kod i wyszło mi, że pierwsze wstrzyknięcie jest
>> równoważnikiem wywołania new. Kolejne: to już korzystanie z tego obiektu.
>
> W najprostszym przypadku tak właśnie jest. Ale zadaniem autowiringu nie
> jest proste tworzenie obiektów, tylko wyciąganie ich z kontenera. Gdzie
> najczęściej są już skonfigurowane.
> Mam wrażenie, że kompletnie pominąłeś ten temat w Laravelu, choć było to
> tłumaczone.
stanie ogarnąć ideologii. Czytałem niektóre rozdziały po 5x testując
równolegle kod. Nie mając w głowie całej tej ideologii, nie byłem w
stanie wyobrazić sobie aplikacji.
Zapoznając się z Symfonią mam wrażenie, że jest ona prosta jak pisanie w
czystym PHP. Bez bełkotu fasadowego, który czasem nawet jedną PHPową
funkcję zamykał w sobie, by ją pod inną nazwą udostępnić. A do tego nie
było szans na analizę źródeł gdy coś w dokumentacji nie było jasne bo
źródła w Laravelu to najczęściej 1-linijkowy kod, który zwykle woła inny
1-linijkowy kod a ten kolejny. Udało mi się w ten sposób prześledzić
kilkanaście poziomów zagnieżdżenia i niczego się nie dowiedzieć. Swoją
drogą jak potężny stos musi tworzyć aplikacja "hello world" w Laravelu,
to sobie nie jestem w stanie wyobrazić nawet. W Symfonii kod frameworka
może czasem za dokumentację robić.
Dlatego odniosłeś wrażenie, że pominąłem całą sekcję dokumentacji.
Chiński bym szybciej pojął.
>> Dziś dyskutowałem z kolegą na ten sam temat. Zwrócił mi uwagę na pewną
>> cechę Symfony. Można w niej zwyczajnie osadzać w twigach dowolną ilość
>> kontrolerów i wskazywać na metody jakie mają renderować dany fragment.
>> Tak na marginesie w Laravelu to było niby też możliwe ale i tak bardzo
>> ograniczone funkcjonalnie - m.in. dlatego pożegnałem ten framework.
>
> I bardzo dobrze, że tak było, bo rozrzucanie logiki po wielu kontrolerach
> to średni pomysł i szybka droga do bałaganu w kodzie, którego już nikt poza
> autorem nie ogarnie.
renderowanie za pomocą 1 kontrolera na stronie generowanej z udziałem
kilku innych kontrolerów. W Laravelu każdy podobny do w/w funkcjonalnie
kontroler musiał mieć brata bliźniaka w postaci serwisu, bo tylko
serwisy dawało się osadzać. Więc w laravelu jedna funkcjonalność była
rozwalona na przynajmniej 2 pliki. A w Symfonii masz tylko 1 przecież.
Nie wspominając o konieczności rozbijania jednej złożonej strony na
wiele blade'ów zamiast umieszczania prostych bloczków typu
render(controller + twig do niego). Wtedy twig podąża za kontrolerem
przenosząc taki bloczek w inne miejsce.
Właśnie to bałaganiarstwo Laravela też było gwoździem do trumny.
Oczywiście opisuję swoje wrażenia.
> Mógłbym zrobić Ci wykład z dbania o poprawne nazewnictwo w kodzie, również
> testowym, który pokazujesz światu. Ale... chyba nie ma sensu.
będzie istnieć przez kilka minut - aż sprawdzę jak jakiś mechanizm
działa a potem ją skasuję.
Powiedz mi zatem, jak Ty dbasz o poprawne nazewnictwo w takich
przypadkach? Czy tworzysz sekcje autodokumentacji do takich metod?
Pchasz to na Gita? Opisujesz potem powody usunięcia tejże funkcji w
commitach? Czy tą czynność rejestrujesz np. w Sprintach na Scumie?
Tworzysz do niej backloga na Agile Acceleratorze i powołujesz się na ID
ticketu w commitach? Masz jakiegoś testera, któremu zlecasz testy kodu
pokroju "hello world"?
A czy gdy testujesz fragment kodu na np. PHP Sandboxie (taka strona
WWW), to również dbasz tam o takie rzeczy skoro po zamknięciu
przeglądarki kod i tak zniknie?
Serio?
Sorki, ale wydaje mi się paranoją dbanie o czystość chwilowego kodu.
Trzeba mieć naprawdę nadmiar wolnego czasu by tak postępować. Kod
którego nikt nigdy nie zobaczy bo zniknie po paru minutach egzystencji,
przy takim postępowaniu rozpościera się na dni pracy.
>> A różnie. W ramach testów zmieniam do woli jej funkcjonalność.
>> Pierwotnie była to tablica, a teraz kolekcja ORM. Jutro być może będzie
>> coś innego :-D
>
> I my mamy zgadywać?
zdefiniowaną funkcjonalność tej metody? Załóżmy, że kosi trawnik.
Ona po prostu tam jest. Załóż, że nic nie zwraca a my chcemy ją tylko
wywołać z parametrem jakimś (np. wartość int). Tymczasem wstrzyknięcie
serwisu do metody blokuje możliwość przekazanie parametru do niej, bo
spodziewa się MarekService, a nie int'a.
> Bardzo prosto, zaglądasz do źródeł. getFlash() to jest helper:
>
> https://github.com/symfony/symfony/blob/4.0/src/Symfony/Bundle/FrameworkBundle/Templating/Helper/SessionHelper.php#L45
>
Zresztą nawet jeśli byłby tam on, to dowiadywanie się o istnieniu (w
dodatku powszechnie stosowanych) funkcji/metod poprzez analizę źródeł
zamiast szybkiego dowiedzenia się w dokumentacji, jest lekko dziwne...
--
Pozdrawiam,
Marek
Borys Pogoreło
Apr 17, 2019, 4:36:19 AM4/17/19
to
Dnia Wed, 17 Apr 2019 00:11:37 +0200, Marek S napisał(a):
> Zapoznając się z Symfonią mam wrażenie, że jest ona prosta jak pisanie w
> czystym PHP.
Bo taka jest idea Symfony - jest to stosunkowo niskopoziomowy framework /
> Zapoznając się z Symfonią mam wrażenie, że jest ona prosta jak pisanie w
> czystym PHP.
zbiór komponentów, z którego dopiero musisz zbudować co potrzebujesz. Nie
ma sensu porównywać obu tych frameworków pod tym kątem, bo są zupełnie
inne. Zresztą, Laravel też jest zbudowany w dużej mierze na Symfony.
> Swoją drogą jak potężny stos musi tworzyć aplikacja "hello world" w
> Laravelu, to sobie nie jestem w stanie wyobrazić nawet.
> Dlatego odniosłeś wrażenie, że pominąłem całą sekcję dokumentacji.
> Chiński bym szybciej pojął.
> Nie rozumiem? W Symfonii udało mi się zrobić przeglądarkę newsów i jej
> renderowanie za pomocą 1 kontrolera na stronie generowanej z udziałem
> kilku innych kontrolerów. W Laravelu każdy podobny do w/w funkcjonalnie
> kontroler musiał mieć brata bliźniaka w postaci serwisu, bo tylko
> serwisy dawało się osadzać. Więc w laravelu jedna funkcjonalność była
> rozwalona na przynajmniej 2 pliki. A w Symfonii masz tylko 1 przecież.
> Nie wspominając o konieczności rozbijania jednej złożonej strony na
> wiele blade'ów zamiast umieszczania prostych bloczków typu
> render(controller + twig do niego). Wtedy twig podąża za kontrolerem
> przenosząc taki bloczek w inne miejsce.
> A czy gdy testujesz fragment kodu na np. PHP Sandboxie (taka strona
> WWW), to również dbasz tam o takie rzeczy skoro po zamknięciu
> przeglądarki kod i tak zniknie?
publiczny z pytaniem czemu nie działa, to zadbałbym o jego maksymalną
czytelność. Bo jeśli fragment, o który pytasz, nawet nie wiadomo do końca
co robi, to wielu sobie odpuści.
> Ona po prostu tam jest. Załóż, że nic nie zwraca a my chcemy ją tylko
> wywołać z parametrem jakimś (np. wartość int). Tymczasem wstrzyknięcie
> serwisu do metody blokuje możliwość przekazanie parametru do niej, bo
> spodziewa się MarekService, a nie int'a.
do której możesz przekazać parametry jakie chcesz. Masz na myśli parametry
konstruktora?
> Ale tam też nie ma addFash(), o który pytam :-(
https://github.com/symfony/symfony/blob/1fcc99402137471d68996ffb4b466e3aaee19447/src/Symfony/Bundle/FrameworkBundle/Controller/ControllerTrait.php#L157
> Zresztą nawet jeśli byłby tam on, to dowiadywanie się o istnieniu (w
> dodatku powszechnie stosowanych) funkcji/metod poprzez analizę źródeł
> zamiast szybkiego dowiedzenia się w dokumentacji, jest lekko dziwne...
drugi kod źródłowy...
--
Borys Pogoreło
borys(#)leszno,edu,pl
Marek S
Apr 17, 2019, 4:26:55 PM4/17/19
to
W dniu 2019-04-17 o 10:36, Borys Pogoreło pisze:
> Bo taka jest idea Symfony - jest to stosunkowo niskopoziomowy framework /
> zbiór komponentów, z którego dopiero musisz zbudować co potrzebujesz.
No chwila. Zacytuję Twoje słowa z innego wątku, gdy to samo powiedziałem:
"No to teraz żeś pojechał po bandzie...
Ale powodzenia"
> Nie
> ma sensu porównywać obu tych frameworków pod tym kątem, bo są zupełnie
> inne. Zresztą, Laravel też jest zbudowany w dużej mierze na Symfony.
Tak, widziałem iż sporo rzeczy dociąganych jest z Symfony. Sęk w tym, że
implementacja tych dobrodziejstw w Laravelu kojarzy mi się z brodzeniem
po pas w szambie by po omacku wyłowić te proste mechanizmy oblane
fasadami tylko po to by łatwo nie było.
>> Swoją drogą jak potężny stos musi tworzyć aplikacja "hello world" w
>> Laravelu, to sobie nie jestem w stanie wyobrazić nawet.
>
> Kilkadziesiąt wywołań, ale Ciebie interesują z reguły te ostatnie.
Jasne, oczywiście. Tylko nie o to mi chodziło :-) Kilkadziesiąt
wywołań.... dobrze, że stack overflow się nie pojawił. Oczywiście ironizuję.
>> Dlatego odniosłeś wrażenie, że pominąłem całą sekcję dokumentacji.
>> Chiński bym szybciej pojął.
>
> No patrz, a większość świata uważa, że Laravel jest prostszy do ogarnięcia.
Mierzę swoją miarą. Tak jak pisałem: w tydzień samoedukacji robię takie
rzeczy jak w Laravelu po miesiącu za diabła nie potrafiłem.
>
> Mam wrażenie, że inaczej nazywamy te same rzeczy. Daj przykład.
W zasadzie opisałem to poniżej i skomentowałeś to. Ale przeczytaj moją
odpowiedź.
>
>> Nie wspominając o konieczności rozbijania jednej złożonej strony na
>> wiele blade'ów zamiast umieszczania prostych bloczków typu
>> render(controller + twig do niego). Wtedy twig podąża za kontrolerem
>> przenosząc taki bloczek w inne miejsce.
>
> I tak oto opisałeś View Composer - do którego Cię też już odsyłałem.
Tak, zgadza się, że odsyłałeś. I wyczytałem w nim, że composery budujemy
w oparciu o ServiceProvider's. ServiceProviders nie potrafią obsłużyć
akcji, bo do tego służą kontrolery. Więc rysujemy ServiceProviderami
poprzez View Composer, a akcje przechwytujemy Kontrolerami tylko po to
by i tak przekazać te zdarzenia do ServiceProviderów by zaktualizowały
wyświetlaną treść. Ale na tym nie koniec bo jeszcze ServiceProvidera
trzeba osadzić w blade, który generuje bloki kodu HTML. Tego blade trzeba:
1) includować do layoutu
2) przewidzieć w layoucie miejsce na bloki kodu wygenerowane w 1)
3) powstawiać treści poprzez chyba yield/parent (już nie pamiętam)
Gdy klient zmieni zdanie i trzeba przenieść działanie powyższego na
jakąś inną podstronę, to musimy mozolnie bloczek po bloczku pozabierać.
W Symfony używam do obu celów jednego kontrolera poprzez
render(controler name + twig name) - opisowo. Zajmuje to 1 linijkę w
twigu. Jeśli klientowi nie odpowiada generowana kolumna newsów
(przykładowo), to przenoszę tę jedną linijkę kodu na inną podstronę.
Banalne! Nie pierdzielę się z siatką powiązań.
>> A czy gdy testujesz fragment kodu na np. PHP Sandboxie (taka strona
>> WWW), to również dbasz tam o takie rzeczy skoro po zamknięciu
>> przeglądarki kod i tak zniknie?
>
> Oczywiście, że nie. Ale jeśli bym wystawiał jakiś kawałek kodu na widok
> publiczny z pytaniem czemu nie działa, to zadbałbym o jego maksymalną
> czytelność. Bo jeśli fragment, o który pytasz, nawet nie wiadomo do końca
> co robi, to wielu sobie odpuści.
Ok, ja to rozumiem. Tylko jaki jest sens opisywania, co dana metoda robi
skoro nie tego dotyczyło moje pytanie. Chodziło mi o sposób
przekazywania parametrów do jakiejkolwiek funkcji jeśli wstrzyknięcia
czegokolwiek blokują mi tą możliwość.
Co za różnica jak te funkcje się nazywają - jak je nazwiesz, takie będą.
Można pojechać z ich nazwami z Lorem Ipsum bo nie ma to żadnego
znaczenia. Mnie interesują tylko te dwa nawiasy, które są za każdą nazwą
funkcji.
Obrazowo: jadę do mechanika bo wycieraczki mi się zużyły a ja nie
potrafię ich zmienić. Mechanik zaczyna mnie się dopytywać o ciśnienie
sprężania w komorze cylindra. Wierci mi dziurę w brzuchu, że jadę na
zmianę wycieraczek a ja się nie przygotowałem bo nie znam wartości tego
ciśnienia. Zadaje pytania czy wtryski nie leją i czy zwrotnica turbiny
się nie zacina. Po co tak?
> Dalej nie rozumiem. Przecież tam wołasz metodę getRandom() na tym obiekcie,
> do której możesz przekazać parametry jakie chcesz. Masz na myśli parametry
> konstruktora?
To może obrazowo. Funkcja wygląda następująco:
private function getRandom(MarekService $marekService)
Czy tak?
Ja chcę przekazać jej wartość 1234 bo jest mi to do czegoś potrzebne w
ciele tejże funkcji. Co zrobi następujący fragment kodu?
$this->getRandom(1234)
Wywali się! Zresztą chyba sobie sam odpowiedziałem na pytanie jak należy
problem rozwiązać. Coś mnie przymuliło, że na to nie wpadłem. Sypiam po
kilka godzin przez ostatnie dni, więc na prostych rzeczach się
wykładam... Sorki. Funkcja po modyfikacji powinna wyglądać tak:
private function getRandom(int $ukochanaLiczba, MarekService
$marekService)
... i takiej odpowiedzi oczekiwałem.
I jeszcze raz: co miałby usprawnić gdybym wymyślił jakąkolwiek
funkcjonalność dla tej funkcji?
>> Ale tam też nie ma addFash(), o który pytam :-(
>
> Ten jest tutaj:
> https://github.com/symfony/symfony/blob/1fcc99402137471d68996ffb4b466e3aaee19447/src/Symfony/Bundle/FrameworkBundle/Controller/ControllerTrait.php#L157
Wow! W dodatku jest to trait! Więc addFlash() będzie dostępny tylko tam,
gdzie framework osadza tego traita. Czyli jak wylistować klasy z tym
traitem by dowiedzieć się czy przypadkiem jedna z nich nie jest używana
przeze mnie jako bazowa?
Teraz najbardziej interesuje mnie sposób docierania do takich
informacji. Ale za nim o tym na końcu.
Pamiętasz, co pisałem o Laravelu? Gdybyś chciał dotrzeć do podobnej
funkcji w źródłach Laravela, to ścieżka miałaby kilkadziesiąt wywołań i
obrazowo wyglądała by tak:
App::addFlash() { return App::cosTam() {return NieApp::cosInnego() .....
Zagniezdzenie52::ostatniaFunkcja() {return "i tak tu kodu nie
znajdziesz"} } ;}
> Gdyby w dokumentacji mieli opisywać każdą pojedynczą metodę, to powstałby
> drugi kod źródłowy...
To lepiej nie wiedzieć o istnieniu jakiejkolwiek metody? W Laravelu lub
Yii jakoś nie mieli z tym problemu. A popatrz na dokumentację PHP.
Mogliby też źródła podać a mimo to...
Da się? Da się!
Trudno mi sobie wyobrazić naukę frameworka z jego źródeł.
A teraz na przykładzie addFlash(). Jak jego znalazłeś? Interesuje mnie
metodyka. Ja szukałem w Google "symfony addFlash" i poddałem się widząc
rezultaty. W życiu bym nie wpadł, że trzeba otworzyć jeden z 9785676
plików Symfony i mieć tyle szczęścia by go w trafić w pierwszej setce
podejść.
Czy ściągasz kompletne środowisko Symfony na dysk, by potem użyć
wyszukiwarki z jakiegoś IDE? Mi PHPStorm domyślnie wyłącza vendor'a by
nie zaśmiecać wyników wyszukiwania. I tak jest moim zdaniem lepiej.
--
Pozdrawiam,
Marek
> Bo taka jest idea Symfony - jest to stosunkowo niskopoziomowy framework /
> zbiór komponentów, z którego dopiero musisz zbudować co potrzebujesz.
"No to teraz żeś pojechał po bandzie...
Ale powodzenia"
> Nie
> ma sensu porównywać obu tych frameworków pod tym kątem, bo są zupełnie
> inne. Zresztą, Laravel też jest zbudowany w dużej mierze na Symfony.
implementacja tych dobrodziejstw w Laravelu kojarzy mi się z brodzeniem
po pas w szambie by po omacku wyłowić te proste mechanizmy oblane
fasadami tylko po to by łatwo nie było.
>> Swoją drogą jak potężny stos musi tworzyć aplikacja "hello world" w
>> Laravelu, to sobie nie jestem w stanie wyobrazić nawet.
>
> Kilkadziesiąt wywołań, ale Ciebie interesują z reguły te ostatnie.
wywołań.... dobrze, że stack overflow się nie pojawił. Oczywiście ironizuję.
>> Dlatego odniosłeś wrażenie, że pominąłem całą sekcję dokumentacji.
>> Chiński bym szybciej pojął.
>
> No patrz, a większość świata uważa, że Laravel jest prostszy do ogarnięcia.
rzeczy jak w Laravelu po miesiącu za diabła nie potrafiłem.
>
> Mam wrażenie, że inaczej nazywamy te same rzeczy. Daj przykład.
odpowiedź.
>
>> Nie wspominając o konieczności rozbijania jednej złożonej strony na
>> wiele blade'ów zamiast umieszczania prostych bloczków typu
>> render(controller + twig do niego). Wtedy twig podąża za kontrolerem
>> przenosząc taki bloczek w inne miejsce.
>
> I tak oto opisałeś View Composer - do którego Cię też już odsyłałem.
w oparciu o ServiceProvider's. ServiceProviders nie potrafią obsłużyć
akcji, bo do tego służą kontrolery. Więc rysujemy ServiceProviderami
poprzez View Composer, a akcje przechwytujemy Kontrolerami tylko po to
by i tak przekazać te zdarzenia do ServiceProviderów by zaktualizowały
wyświetlaną treść. Ale na tym nie koniec bo jeszcze ServiceProvidera
trzeba osadzić w blade, który generuje bloki kodu HTML. Tego blade trzeba:
1) includować do layoutu
2) przewidzieć w layoucie miejsce na bloki kodu wygenerowane w 1)
3) powstawiać treści poprzez chyba yield/parent (już nie pamiętam)
Gdy klient zmieni zdanie i trzeba przenieść działanie powyższego na
jakąś inną podstronę, to musimy mozolnie bloczek po bloczku pozabierać.
W Symfony używam do obu celów jednego kontrolera poprzez
render(controler name + twig name) - opisowo. Zajmuje to 1 linijkę w
twigu. Jeśli klientowi nie odpowiada generowana kolumna newsów
(przykładowo), to przenoszę tę jedną linijkę kodu na inną podstronę.
Banalne! Nie pierdzielę się z siatką powiązań.
>> A czy gdy testujesz fragment kodu na np. PHP Sandboxie (taka strona
>> WWW), to również dbasz tam o takie rzeczy skoro po zamknięciu
>> przeglądarki kod i tak zniknie?
>
> Oczywiście, że nie. Ale jeśli bym wystawiał jakiś kawałek kodu na widok
> publiczny z pytaniem czemu nie działa, to zadbałbym o jego maksymalną
> czytelność. Bo jeśli fragment, o który pytasz, nawet nie wiadomo do końca
> co robi, to wielu sobie odpuści.
skoro nie tego dotyczyło moje pytanie. Chodziło mi o sposób
przekazywania parametrów do jakiejkolwiek funkcji jeśli wstrzyknięcia
czegokolwiek blokują mi tą możliwość.
Co za różnica jak te funkcje się nazywają - jak je nazwiesz, takie będą.
Można pojechać z ich nazwami z Lorem Ipsum bo nie ma to żadnego
znaczenia. Mnie interesują tylko te dwa nawiasy, które są za każdą nazwą
funkcji.
Obrazowo: jadę do mechanika bo wycieraczki mi się zużyły a ja nie
potrafię ich zmienić. Mechanik zaczyna mnie się dopytywać o ciśnienie
sprężania w komorze cylindra. Wierci mi dziurę w brzuchu, że jadę na
zmianę wycieraczek a ja się nie przygotowałem bo nie znam wartości tego
ciśnienia. Zadaje pytania czy wtryski nie leją i czy zwrotnica turbiny
się nie zacina. Po co tak?
> Dalej nie rozumiem. Przecież tam wołasz metodę getRandom() na tym obiekcie,
> do której możesz przekazać parametry jakie chcesz. Masz na myśli parametry
> konstruktora?
private function getRandom(MarekService $marekService)
Czy tak?
Ja chcę przekazać jej wartość 1234 bo jest mi to do czegoś potrzebne w
ciele tejże funkcji. Co zrobi następujący fragment kodu?
$this->getRandom(1234)
Wywali się! Zresztą chyba sobie sam odpowiedziałem na pytanie jak należy
problem rozwiązać. Coś mnie przymuliło, że na to nie wpadłem. Sypiam po
kilka godzin przez ostatnie dni, więc na prostych rzeczach się
wykładam... Sorki. Funkcja po modyfikacji powinna wyglądać tak:
private function getRandom(int $ukochanaLiczba, MarekService
$marekService)
... i takiej odpowiedzi oczekiwałem.
I jeszcze raz: co miałby usprawnić gdybym wymyślił jakąkolwiek
funkcjonalność dla tej funkcji?
>> Ale tam też nie ma addFash(), o który pytam :-(
>
> Ten jest tutaj:
> https://github.com/symfony/symfony/blob/1fcc99402137471d68996ffb4b466e3aaee19447/src/Symfony/Bundle/FrameworkBundle/Controller/ControllerTrait.php#L157
gdzie framework osadza tego traita. Czyli jak wylistować klasy z tym
traitem by dowiedzieć się czy przypadkiem jedna z nich nie jest używana
przeze mnie jako bazowa?
Teraz najbardziej interesuje mnie sposób docierania do takich
informacji. Ale za nim o tym na końcu.
Pamiętasz, co pisałem o Laravelu? Gdybyś chciał dotrzeć do podobnej
funkcji w źródłach Laravela, to ścieżka miałaby kilkadziesiąt wywołań i
obrazowo wyglądała by tak:
App::addFlash() { return App::cosTam() {return NieApp::cosInnego() .....
Zagniezdzenie52::ostatniaFunkcja() {return "i tak tu kodu nie
znajdziesz"} } ;}
> Gdyby w dokumentacji mieli opisywać każdą pojedynczą metodę, to powstałby
> drugi kod źródłowy...
Yii jakoś nie mieli z tym problemu. A popatrz na dokumentację PHP.
Mogliby też źródła podać a mimo to...
Da się? Da się!
Trudno mi sobie wyobrazić naukę frameworka z jego źródeł.
A teraz na przykładzie addFlash(). Jak jego znalazłeś? Interesuje mnie
metodyka. Ja szukałem w Google "symfony addFlash" i poddałem się widząc
rezultaty. W życiu bym nie wpadł, że trzeba otworzyć jeden z 9785676
plików Symfony i mieć tyle szczęścia by go w trafić w pierwszej setce
podejść.
Czy ściągasz kompletne środowisko Symfony na dysk, by potem użyć
wyszukiwarki z jakiegoś IDE? Mi PHPStorm domyślnie wyłącza vendor'a by
nie zaśmiecać wyników wyszukiwania. I tak jest moim zdaniem lepiej.
--
Pozdrawiam,
Marek
Borys Pogoreło
Apr 30, 2019, 10:12:53 AM4/30/19
to
Dnia Wed, 17 Apr 2019 22:26:50 +0200, Marek S napisał(a):
> Tak, widziałem iż sporo rzeczy dociąganych jest z Symfony. Sęk w tym, że
> implementacja tych dobrodziejstw w Laravelu kojarzy mi się z brodzeniem
> po pas w szambie by po omacku wyłowić te proste mechanizmy oblane
> fasadami tylko po to by łatwo nie było.
Jestem ciekaw, kiedy odkryjesz, że Symfony jest zbudowane na identycznej
> Tak, widziałem iż sporo rzeczy dociąganych jest z Symfony. Sęk w tym, że
> implementacja tych dobrodziejstw w Laravelu kojarzy mi się z brodzeniem
> po pas w szambie by po omacku wyłowić te proste mechanizmy oblane
> fasadami tylko po to by łatwo nie było.
idei kontenera IoC. Jedynie nie ma "fasad".
> Tak, zgadza się, że odsyłałeś. I wyczytałem w nim, że composery budujemy
> w oparciu o ServiceProvider's.
> ServiceProviders nie potrafią obsłużyć akcji, bo do tego służą
> kontrolery. Więc rysujemy ServiceProviderami poprzez View Composer, a
> akcje przechwytujemy Kontrolerami tylko po to by i tak przekazać te
> zdarzenia do ServiceProviderów by zaktualizowały wyświetlaną treść. Ale
> na tym nie koniec bo jeszcze ServiceProvidera trzeba osadzić w blade,
> który generuje bloki kodu HTML. Tego blade trzeba:
OMG, ja nie wiem co Ty wyprodukowałeś w tym kodzie, ale po trzecim
przeczytaniu poddałem się. Ja nigdy nie miałem potrzeby zbudowania czegoś
tak skomplikowanego, tym bardziej do bloczka wyświetlającego produktu.
Ergo, robisz coś źle i/lub za mało poznałeś koncepcje rządzącę
frameworkiem.
> W Symfony używam do obu celów jednego kontrolera poprzez
> render(controler name + twig name) - opisowo. Zajmuje to 1 linijkę w
> twigu. Jeśli klientowi nie odpowiada generowana kolumna newsów
> (przykładowo), to przenoszę tę jedną linijkę kodu na inną podstronę.
> Banalne! Nie pierdzielę się z siatką powiązań.
przenieść jakieś @section / @component / w ostatecznosci @inject +
odwołanie.
> Co za różnica jak te funkcje się nazywają - jak je nazwiesz, takie będą.
> Można pojechać z ich nazwami z Lorem Ipsum bo nie ma to żadnego
> znaczenia.
> private function getRandom(int $ukochanaLiczba, MarekService
> $marekService)
> Wow! W dodatku jest to trait! Więc addFlash() będzie dostępny tylko tam,
> gdzie framework osadza tego traita. Czyli jak wylistować klasy z tym
> traitem by dowiedzieć się czy przypadkiem jedna z nich nie jest używana
> przeze mnie jako bazowa?
> Pamiętasz, co pisałem o Laravelu? Gdybyś chciał dotrzeć do podobnej
> funkcji w źródłach Laravela, to ścieżka miałaby kilkadziesiąt wywołań i
> obrazowo wyglądała by tak:
> Trudno mi sobie wyobrazić naukę frameworka z jego źródeł.
nietypowego. Przykładowo w Laravelu dynamicznie utworzyć adapter FlySystem
nie korzytający z konfiguracji frameworka. Rzecz banalna, gdy zajrzysz do
źródeł, ale nikt nie będzie tego dokumentował dla tych pięciu
zainteresowanych osób.
> A teraz na przykładzie addFlash(). Jak jego znalazłeś? Interesuje mnie
> metodyka. Ja szukałem w Google "symfony addFlash" i poddałem się widząc
> rezultaty. W życiu bym nie wpadł, że trzeba otworzyć jeden z 9785676
> plików Symfony i mieć tyle szczęścia by go w trafić w pierwszej setce
> podejść.
całego projektu. Albo w GitHubie.
--
Borys Pogoreło
borys(#)leszno,edu,pl
0 new messages