🚀 go-pugleaf

Dnia Tue, 16 Apr 2019 23:19:13 +0200, Marek S napisał(a):

>> Wcale nie musisz ich używać. Ja jestem z tej połowy, która uważa je za
>> bezsens.
> 
> Niestety w kursach jakie wykupiłem nie wspomniano o takiej opcji. :-(

Bo kurs zakłada jakiś scenariusz i go opisuje według tego, co dany autor
uważa za słuszne. Chcesz kontrowersji i różnych punktów widzenia, to trzeba
czytać dyskusje w sieci.

> Hmmm... ja to widzę inaczej już teraz, na początku. Zaczynam projekt, 
> potrzebuję np. doktryn, to je szybciutko dociągam. W PHPStorm to już w 
> ogóle bajka bo CTRL+Shift+X potem S, potem doctr i enter. To nie jest 
> orka lecz niezauważalna czynność obsługowa. Podobnie z innymi.

To jest akurat najmniejszy problem. Ale jak będziesz musiał to wszystko
zestawić ze sobą, by "zagrało", to wtedy zaczynają się schody. A i tak w
Symfony 4 jest już dużo prościej, wcześniej to była orka na ugorze.

> Możliwe. Powiem Ci, że konkretnie poległem na stronie z 2ma sekcjami po 
> 3 newsy, które miały możliwość przełączania na kolejne 3 w danej 
> kolumnie. Założenie: zero Ajaxa. Zrobiłem więc w layoucie miejsce na 
> nie. Do tego dwa dołączone includami z wstrzykniętymi serwisami 
> generującymi dane do wyświetlenia. Kontrolerów nie da się wstrzykiwać w 
> Laravelu. Kliknięcie "następne 3" odwoływało się do kontrolera danej 
> sekcji, które był tylko po to by przekazać serwisowi informację o 
> zdarzeniu i potem powrót do strony głównej.

I po raz kolejny pada hasło "View Composer". Nie wiem po co tu jeszcze
tworzyć jakieś dodatkowe kontrolery, które zapewne jeszcze muszą pilnować
stanu każdej z tych sekcji, zamiast czytać ustawienia z parametrów GET.

> Jaka z tego konsekwencja? A no taka, że gdy klientowi odwidzi się jakiś 
> blok w danej lokalizacji, to go zabieram z niej i pakuję w inne miejsce 
> - bez programowania. Tzn. nie muszę przenosić obsługi serwisów do innych 
> kontrolerów. Zmieniam tylko część wizualną.a soft zostaje.

No popatrz, tak samo byś to mógł zrobić z View Composerem.

> Czy to nie jest przypadkiem coś takiego jak dziedziczenie, polimorfizm, 
> interfejsy? Być może nie znam. Przyjmijmy więc zatem, że uwielbiam 
> używać "extends coś mojego", stosować abstrakcje czy final, mieć klasy o 
> dowolnej zawartości, która mi odpowiada a nie framework narzuca. Laravel 
> dawał mi fasady, z których korzystanie bardziej przypominało mi pracę 
> urzędnika niż programisty. :-D

Ale co mają wspólnego te nieszczęsne fasady z tym, jak możesz organizować
swój własny kod? One służą wyłącznie do sięgnięcia do usług, które się za
nimi kryją.

> Ale jak zdefiniowane? Ja dostawałem coś takiego w nich:
> 
>      public function up()
>      {
>          Schema::create('flights', function (Blueprint $table) {
>              $table->increments('id');
>              $table->string('name');
>              $table->string('airline');
>              $table->timestamps();
>          });
>      }
> 
> Dla mnie to bełkot. To się półautomatycznie tworzyło.

I co z tym jest nie tak? Wszystko jak na dłoni. Właśnie widzę w wątku obok,
jak podobnie narzekasz na Doctrine.

>> W każdej chwili możesz napisać DB::query().
> 
> I znów fasada... ech... SQL to tekst prosty, zwięzły, przejrzysty. komu 
> on szkodzi, ze tak jest tępiony? Podoba mi się w Symfonii, że w 
> doktrynach jest on natywnie stosowany.

Rany, to tylko metoda sięgnięcia po obiekt połączenia z bazą danych z
kontenera. Chcesz "po bożemu", to możesz zrobić:
app()->make(\Illuminate\Database\DatabaseManager::class)->connection()->query(...)
Ale chyba jednak w tym przypadku "fasada" trochę ułatwia życie.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl