🚀 go-pugleaf

Masz zainstalowanego gita ?

W dniu 2019-04-11 o 19:14, Rafal Podsiadly pisze:
> Masz zainstalowanego gita ?

Tak. Sądzisz, ze to on ponosi winę za to? Mam go odinstalować?

-- 
Pozdrawiam,
Marek

W dniu 2019-04-10 o 23:35, Marek S pisze:

> Czy komukolwiek udało się zainstalować Symfonię 4.2.5 począwszy od 
> skeletona? Jest to wykonalne? Jak sobie z tym radzić?
> 

Znalazłem odpowiedź. Gdy używamy XAMPPa, to bezwzględnie należy 
zatrzymać Apache oraz zamknąć okno sterowania (quit). Jeśli pominiemy 
jeden z tych kroków, composer będzie czynił przeróżne niespodzianki, 
choć nie zawsze.

-- 
Pozdrawiam,
Marek

Do której wersji php masz skonfigurowaną zmienną środowiskową patch
Czy używasz gitbash do instalacji symfony ?
Czy używasz composer.phar czy coposer exe ? czy masz masz dodaną sciężkę do composer w patch ?

W dniu 2019-04-12 o 20:12, Rafal Podsiadly pisze:
> Do której wersji php masz skonfigurowaną zmienną środowiskową patch

Masz na myśli PATH, nie PATCH?
Wersję PHP mam zawsze bieżącą. U mnie jest ona w C:\xampp\php i tam 
wskazuje PATH.

> Czy używasz gitbash do instalacji symfony ?

Tak, ale na zwykłym terminalu to samo.

> Czy używasz composer.phar czy coposer exe ? 

EXE

> czy masz masz dodaną sciężkę do composer w patch ?
> 

Mam dwie:
C:\Users\xxxxxx\AppData\Roaming\Composer\vendor\bin;
C:\ProgramData\ComposerSetup\bin;

-- 
Pozdrawiam,
Marek

W dniu sobota, 13 kwietnia 2019 12:01:29 UTC+2 użytkownik Marek S napisał:
> W dniu 2019-04-12 o 20:12, Rafal Podsiadly pisze:
> > Do której wersji php masz skonfigurowaną zmienną środowiskową patch
> 
> Masz na myśli PATH, nie PATCH?
> Wersję PHP mam zawsze bieżącą. U mnie jest ona w C:\xampp\php i tam 
> wskazuje PATH.
> 
> > Czy używasz gitbash do instalacji symfony ?
> 
> Tak, ale na zwykłym terminalu to samo.
> 
> > Czy używasz composer.phar czy coposer exe ? 
> 
> EXE
> 
> > czy masz masz dodaną sciężkę do composer w patch ?
> > 
> 
> Mam dwie:
> C:\Users\xxxxxx\AppData\Roaming\Composer\vendor\bin;
> C:\ProgramData\ComposerSetup\bin;
> 
> -- 
> Pozdrawiam,
> Marek


Co tutaj masz 
> C:\Users\xxxxxx\AppData\Roaming\Composer\vendor\bin; ? 

W dniu 2019-04-14 o 20:51, Rafal Podsiadly pisze:
> 
> Co tutaj masz
>> C:\Users\xxxxxx\AppData\Roaming\Composer\vendor\bin; ?

Ups, to Laravel dodał tu swoje pliki. Są tu laravel i laravel.bat. Można 
więc zignorować.

Ale wiesz? Mam kolejny postęp i chyba to załatwia temat. Otóż nie tyle 
co XAMPP powodował problemy, co konfiguracja PHP pod nim. A wzięła się z 
tego, że grzecznie postępowałem zgodnie z zaleceniami Checkera w 
Symfony. A tam napisali, że jest rekomendowane włączenie... opcache.

Cichcem natomiast pominęli drobnostkę, że będę walczył z composerem, a w 
szczególności z Flexem. Wyłączyłem to g... i wszystkie problemy 
zniknęły. Spróbowałem po raz 76578658 zainstalować od zera Symfony 4 - 
zero niespodzianek...

-- 
Pozdrawiam,
Marek

Dnia Wed, 10 Apr 2019 23:35:02 +0200, Marek S napisał(a):

> Właśnie porzuciłem naukę Laravela, na rzecz łatwiejszej Symfony 4. 

No to teraz żeś pojechał po bandzie...

Ale powodzenia ;)

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

W dniu 2019-04-15 o 00:47, Borys Pogoreło pisze:
> Dnia Wed, 10 Apr 2019 23:35:02 +0200, Marek S napisał(a):
> 
>> Właśnie porzuciłem naukę Laravela, na rzecz łatwiejszej Symfony 4.
> 
> No to teraz żeś pojechał po bandzie...
> 
> Ale powodzenia ;)

hehe... Serio tak to odbieram :-) Oto moje spostrzeżenia jako adepta. W 
Symfony:

- Nie ma wszechobecnych fasad zmieniających proste czynności PHP w 
zaklęcia nowomowy, której od zera trzeba się uczyć. Po cholerę 
standardowy PHP zmieniać na rytuały?

- Nie ma potrzeby instalowania całości internetu by projekt działał. 
Instalujemy skeleton i dociągamy tylko potrzebne rzeczy. W Laravelu 40MB 
plików o prawie zerowej wielkości, mnie nie zachęca.

- W Laravelu nie potrafiłem zbudować strony renderowanej z wielu 
kontrolerów z zapewnieniem funkcjonalności sekcji. Przykładowo kolumna z 
3-ma newsami z NewsController + z 3-ma polecanymi produktami z 
ProductController w taki sposób, aby można było przechodzić bez Ajaxa, 
bez Service Providerów, do następnych trójek. W Symfony z zamkniętymi 
oczami to zrobiłem w kilka chwil. Model programowania w Symfony 
przypomina bardziej MVP zamiast rygorystycznego MVC. Daje to pełnię 
swobody w modyfikowaniu layoutów, gdy klientowi zmieni się koncepcja.

- Routing w Symfony poprzez annotations jest bardzo przejrzysty i 
użyteczny (mimo wcześniejszego mojego dystansu do takich metod).

- Wreszcie w Symfony jest miejsce na programowanie obiektowe. W Laravelu 
programowanie bardziej przypominało wypełnianie formularzy (template'ów 
klas). To mi bardziej przypominało programowanie liniowe.

- W Symfony, automatycznie wygenerowane migracje zawierają SQL. 
Popłakałem się ze szczęścia. Zero ORM'owego bełkotu, który wygeneruje 
nie wiadomo co. W Laravelu na bazie trzeba było sprawdzać czy primary 
key powstał jako 8-bitowy, czy może 4-ro. Czy został utworzony indeks. 
Czy relacja się zawiązała i jakiego typu... A jeśli do tego chciałbym 
np. procedury triggerów obsłużyć w języku PlPgsql to już w ogóle byłaby 
rzeźnia.

Reasumując: w Symfony po 3 dniach nauki osiągnąłem to, co po miesiącu w 
Laravelu. Być może tępy jestem.

-- 
Pozdrawiam,
Marek

Dnia Tue, 16 Apr 2019 00:08:33 +0200, Marek S napisał(a):

> - Nie ma wszechobecnych fasad zmieniających proste czynności PHP w 
> zaklęcia nowomowy, której od zera trzeba się uczyć. Po cholerę 
> standardowy PHP zmieniać na rytuały?

Wcale nie musisz ich używać. Ja jestem z tej połowy, która uważa je za
bezsens.

> - Nie ma potrzeby instalowania całości internetu by projekt działał. 
> Instalujemy skeleton i dociągamy tylko potrzebne rzeczy. W Laravelu 40MB 
> plików o prawie zerowej wielkości, mnie nie zachęca.

Bo taka jest idea tego frameworka. Większość rozwiązań dostarczać gotowe.
Przygotowanie takiego samego boilerplate w Symfony to jest orka na
początku.

> - W Laravelu nie potrafiłem zbudować strony renderowanej z wielu 
> kontrolerów z zapewnieniem funkcjonalności sekcji. 

Jak dla mnie to musiałeś to wyjątkowo źle skonstruować, że miałeś takie
problemy. Albo próbowałeś zbyt skomplikowane rzeczy tworzyć nie znając
zasad rządzących tym narzędziem. To akurat nic złego, bo tak się też
nauczysz, ale trochę za szybko odpuściłeś.

Poza tym, jak już Ci kiedyś pisałem - kontroler jest jeden. Za to dostawców
usług albo repozytoriów możesz mieć ile chcesz.

> - Wreszcie w Symfony jest miejsce na programowanie obiektowe. W Laravelu 
> programowanie bardziej przypominało wypełnianie formularzy (template'ów 
> klas). To mi bardziej przypominało programowanie liniowe.

No to żeś znowu pojechał... Na pewno znasz definicję programowania
obiektowego?

> - W Symfony, automatycznie wygenerowane migracje zawierają SQL. 
> Popłakałem się ze szczęścia. Zero ORM'owego bełkotu, który wygeneruje 
> nie wiadomo co. W Laravelu na bazie trzeba było sprawdzać czy primary 
> key powstał jako 8-bitowy, czy może 4-ro. Czy został utworzony indeks. 
> Czy relacja się zawiązała i jakiego typu... 

Przecież to wszystko masz zdefiniowane w migracjach. Nie rozumiem.

> A jeśli do tego chciałbym np. procedury triggerów obsłużyć w języku 
> PlPgsql to już w ogóle byłaby rzeźnia.

W każdej chwili możesz napisać DB::query().

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

W dniu 2019-04-16 o 17:43, Borys Pogoreło pisze:

> 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. :-(

>> - Nie ma potrzeby instalowania całości internetu by projekt działał.
>> Instalujemy skeleton i dociągamy tylko potrzebne rzeczy. W Laravelu 40MB
>> plików o prawie zerowej wielkości, mnie nie zachęca.
> 
> Bo taka jest idea tego frameworka. Większość rozwiązań dostarczać gotowe.

I właśnie ta idea mnie powaliła na kolana.

> Przygotowanie takiego samego boilerplate w Symfony to jest orka na
> początku.
> 

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.

>> - W Laravelu nie potrafiłem zbudować strony renderowanej z wielu
>> kontrolerów z zapewnieniem funkcjonalności sekcji.
> 
> Jak dla mnie to musiałeś to wyjątkowo źle skonstruować, że miałeś takie
> problemy. Albo próbowałeś zbyt skomplikowane rzeczy tworzyć nie znając
> zasad rządzących tym narzędziem. To akurat nic złego, bo tak się też
> nauczysz, ale trochę za szybko odpuściłeś.

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.

W Symfonii to samo jest banalne: osadzam w layoucie metodę kontrolera, 
która renderuje mi blok newsów na podstawie jakiegoś twiga. Klikam 
"następne 3", gdzie znów odpala się jakaś metoda __TEGO SAMEGO__ 
kontrolera, robi swoje i wraca. Nie ma potrzeby rozbijania obsługi bloku 
newsów na 2 klasy: kontrolera i serwisu. Nie ma potrzeby (=jest wybór) 
includowania zewnętrznych sub-twigów, które dopiero osadzają serwis.

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.

Dla mnie bajka. Tak robiłem kiedyś w swoim własnym frameworku. Uznałem 
wtedy takie "graficzne" podejście za najbardziej wygodne przy realnej 
pracy z klientami.

> Poza tym, jak już Ci kiedyś pisałem - kontroler jest jeden. Za to dostawców
> usług albo repozytoriów możesz mieć ile chcesz.

Tak, pamiętam.

>> - Wreszcie w Symfony jest miejsce na programowanie obiektowe. W Laravelu
>> programowanie bardziej przypominało wypełnianie formularzy (template'ów
>> klas). To mi bardziej przypominało programowanie liniowe.
> 
> No to żeś znowu pojechał... Na pewno znasz definicję programowania
> obiektowego?

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

>> - W Symfony, automatycznie wygenerowane migracje zawierają SQL.
>> Popłakałem się ze szczęścia. Zero ORM'owego bełkotu, który wygeneruje
>> nie wiadomo co. W Laravelu na bazie trzeba było sprawdzać czy primary
>> key powstał jako 8-bitowy, czy może 4-ro. Czy został utworzony indeks.
>> Czy relacja się zawiązała i jakiego typu...
> 
> Przecież to wszystko masz zdefiniowane w migracjach. Nie rozumiem.

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.

> 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.

-- 
Pozdrawiam,
Marek

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