Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.lang.php > #16126 > unrolled thread

Symfony 4 - jaki model routingu wybrać?

Back to article view | Back to pl.comp.lang.php

Contents

  Symfony 4 - jaki model routingu wybrać? Marek S <precz@spamowi.com> - 2019-04-11 22:21 +0200
    Re: Symfony 4 - jaki model routingu wybrać? Rafal Podsiadly <spinacz24@gmail.com> - 2019-04-12 11:19 -0700
      Re: Symfony 4 - jaki model routingu wybrać? Marek S <precz@spamowi.com> - 2019-04-13 11:56 +0200
        Re: Symfony 4 - jaki model routingu wybrać? Wojciech Bancer <wojciech.bancer@gmail.com> - 2019-04-13 15:40 +0200
          Re: Symfony 4 - jaki model routingu wybrać? Marek S <precz@spamowi.com> - 2019-04-13 23:44 +0200
            Re: Symfony 4 - jaki model routingu wybrać? Wojciech Bancer <wojciech.bancer@gmail.com> - 2019-04-14 11:03 +0200
              Re: Symfony 4 - jaki model routingu wybrać? Borys Pogoreło <borys@pl.edu.leszno> - 2019-04-14 13:57 +0200
                Re: Symfony 4 - jaki model routingu wybrać? Wojciech Bancer <wojciech.bancer@gmail.com> - 2019-04-14 14:07 +0200
                  Re: Symfony 4 - jaki model routingu wybrać? Rafal Podsiadly <spinacz24@gmail.com> - 2019-04-14 11:44 -0700

#16126 — Symfony 4 - jaki model routingu wybrać?

Zastanawiam się nad dwoma: annotations/YAML. Ten pierwszy wydaje mi się 
dość kontrowersyjny. Przy dużej ilości kontrolerów ciężko będzie się 
połapać, która ścieżka, do którego kontrolera prowadzi. Z drugiej zaś 
strony obserwuję parcie mechanizmów Symfonii na tą metodę. console 
make:controller ma jako defaultową metodę wybiera annotations właśnie.

Oglądam jakieś tutoriale: tu również zwykle ta metoda jest proponowana.

Dlaczego tak jest? Co polecacie?

-- 
Pozdrawiam,
Marek

[toc] | [next] | [standalone]

#16128

Co wybrać / to kwestia gustu po pracuj z obiema i ocen z czy ci się dobrze pracuje..

Jeśli chodzi o routing to zawsze ma postać drzewa.
/
/admin
/admin/prfile
/admin/module
/user
/user/profile
/user/article
/article
/article/comment

[toc] | [prev] | [next] | [standalone]

#16132

W dniu 2019-04-12 o 20:19, Rafal Podsiadly pisze:
> Co wybrać / to kwestia gustu po pracuj z obiema i ocen z czy ci się dobrze pracuje..
> 
> Jeśli chodzi o routing to zawsze ma postać drzewa.

Moje pytanie było poprzedzone pewną rozmową jaką odbyłem ze znajomym, 
który tworzył w Symfonii 3.x akurat. Powiedział mi on iż routing typu 
"annotations" jest fajny, ale dla małych projektów. Jedyna rzecz jaka 
wydaje mi się zagrożeniem dla "annotations" to jest rozrzucenie ścieżek 
po dziesiątkach (jeśli nie więcej) kontrolerów. Znalezienie właściwego 
po nazwie ścieżki może być kłopotliwe.

Druga rzecz, to grupowanie ścieżek. Np. oddzielne dla zalogowanych i 
oddzielne dla niezalogowanych, oddzielne dla zalogowanych jako np. admin 
itd. Przy annotations tego chyba się nie da czytelnie zrobić?

Jakie masz doświadczenia w tym względzie?

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#16134

On 2019-04-13, Marek S <precz@spamowi.com> wrote:

[...]

>> Co wybrać / to kwestia gustu po pracuj z obiema i ocen z czy ci się dobrze pracuje..
>> 
>> Jeśli chodzi o routing to zawsze ma postać drzewa.
>
> Moje pytanie było poprzedzone pewną rozmową jaką odbyłem ze znajomym, 
> który tworzył w Symfonii 3.x akurat. Powiedział mi on iż routing typu 
> "annotations" jest fajny, ale dla małych projektów. Jedyna rzecz jaka 
> wydaje mi się zagrożeniem dla "annotations" to jest rozrzucenie ścieżek 
> po dziesiątkach (jeśli nie więcej) kontrolerów. Znalezienie właściwego 
> po nazwie ścieżki może być kłopotliwe.

Jak ktoś ma bałagan w projekcie, to nawet routing w 1 pliku będzie problemem.
Anotacje są lepsze, bo umiejscawiają routing w okolicy miejsca do którego on
trafia a nie "gdzieś tam", i nie trzeba skakać po fafnastu plikach, aby dodać
jedną metodę, albo zmodyfikować istniejącą.

Jak ktoś nie ma bałaganu w nazewnictwie kontrolerów (można je przecież grupować 
w katalogach i nazywać w sposób znaczący), to nie będzie miał problemów i 
z routingiem. Jak ktoś ma bałagan, to inne sposoby organizacji (yaml) co najwyżej 
przykryją problem.

A istnieje taka komenda:
$ php bin/console debug:router --show-controllers
i już wszystko widać.

> Druga rzecz, to grupowanie ścieżek. Np. oddzielne dla zalogowanych i 
> oddzielne dla niezalogowanych, oddzielne dla zalogowanych jako np. admin 
> itd. Przy annotations tego chyba się nie da czytelnie zrobić?

Wszystko się da czytelnie zrobić.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

[toc] | [prev] | [next] | [standalone]

#16135

W dniu 2019-04-13 o 15:40, Wojciech Bancer pisze:

> Jak ktoś nie ma bałaganu w nazewnictwie kontrolerów (można je przecież grupować
> w katalogach i nazywać w sposób znaczący), to nie będzie miał problemów i
> z routingiem. Jak ktoś ma bałagan, to inne sposoby organizacji (yaml) co najwyżej
> przykryją problem.

Ok, zatem muszę coś wybrać. Będę budował routing tą techniką. Pewnie 
twórcy "make'a" też z jakiegoś powodu wybrali annotations.

Jak wygląda kwestia zmian w routingu dla dev'a? Np. chciałbym aby jakieś 
sekcje uwidoczniły się lub (być może) ukryły tylko dla dev'a.

> A istnieje taka komenda:
> $ php bin/console debug:router --show-controllers
> i już wszystko widać.

Wow! Super!


-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#16138

On 2019-04-13, Marek S <precz@spamowi.com> wrote:
> W dniu 2019-04-13 o 15:40, Wojciech Bancer pisze:
>
>> Jak ktoś nie ma bałaganu w nazewnictwie kontrolerów (można je przecież grupować
>> w katalogach i nazywać w sposób znaczący), to nie będzie miał problemów i
>> z routingiem. Jak ktoś ma bałagan, to inne sposoby organizacji (yaml) co najwyżej
>> przykryją problem.
>
> Ok, zatem muszę coś wybrać. Będę budował routing tą techniką. Pewnie 
> twórcy "make'a" też z jakiegoś powodu wybrali annotations.
>
> Jak wygląda kwestia zmian w routingu dla dev'a? Np. chciałbym aby jakieś 
> sekcje uwidoczniły się lub (być może) ukryły tylko dla dev'a.

https://stackoverflow.com/questions/51882132/restrict-symfony-4-route-to-the-dev-environment
Z tego co wyczytałem, to trzeba dodać import tych routingów do config/routes/dev

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

[toc] | [prev] | [next] | [standalone]

#16140

Dnia Sun, 14 Apr 2019 11:03:36 +0200, Wojciech Bancer napisał(a):

>> Jak wygląda kwestia zmian w routingu dla dev'a? Np. chciałbym aby jakieś 
>> sekcje uwidoczniły się lub (być może) ukryły tylko dla dev'a.
> 
> https://stackoverflow.com/questions/51882132/restrict-symfony-4-route-to-the-dev-environment
> Z tego co wyczytałem, to trzeba dodać import tych routingów do config/routes/dev

I w ten sposób już tracisz jedyną (i wątpliwą) zaletę annotations, czyli
powiązania ich jednoznacznie z miejscem definicji. Wystarczy, że potrzebny
jest warunek logiczny wykraczający poza te dostarczane przez framework. Ja
ich osobiście nie lubię z tego właśnie powodu, podobnie jak plików YAML
(które do tego dodają kupę problemów z tym formatem jako takim).

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

[toc] | [prev] | [next] | [standalone]

#16141

On 2019-04-14, Borys Pogoreło <borys@pl.edu.leszno> wrote:

[...]

>>> Jak wygląda kwestia zmian w routingu dla dev'a? Np. chciałbym aby jakieś 
>>> sekcje uwidoczniły się lub (być może) ukryły tylko dla dev'a.
>> 
>> https://stackoverflow.com/questions/51882132/restrict-symfony-4-route-to-the-dev-environment
>> Z tego co wyczytałem, to trzeba dodać import tych routingów do config/routes/dev
>
> I w ten sposób już tracisz jedyną (i wątpliwą) zaletę annotations, czyli
> powiązania ich jednoznacznie z miejscem definicji.

Nie. Nie definicje routingu nadal są tam gdzie ich zastosowanie.
W konfiguracji określamy które anotacje ładować (w jakich środowiskach),
czyli określamy loader, a nie same reguły routingu.

> Wystarczy, że potrzebny jest warunek logiczny wykraczający poza te dostarczane 
> przez framework.

To sobie dopiszesz własny loader. 
Odróżniajmy routing od jego loadera.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

[toc] | [prev] | [next] | [standalone]

#16142

W tym przypadku rozwiązania są dwa

przez security
https://symfony.com/doc/current/best_practices/security.html

lub zmienne środowiskowe w /src/Kernel.php

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.lang.php

csiph-web