[SF][Symfony2][SF2] pytanie odnośnie dokumentacji - przykładu, "How to Implement a simple Registration Form" Opcje

[Forti]

How to Implement a simple Registration Form <- to zdanie mówi samo za siebie, prawda?

a teraz pytanie bardzo ważne odnośnie tegoż linku:
http://symfony.com/doc/current/cookbook/do...ation_form.html

Pytanie do tych, co tworzą w symfony: dlaczego ten, kto pisał ten przykład tak bardzo go skomplikował?
Zamiast zrobić prosty warunek dla zaznaczenia akceptacji regulaminu, to mamy - jak na moje oko (krzywe bo krzywe, zmęczone, ale jednak) dwa kontrollery i praktycznie dwa formularze i mase zbędnego kodu.

Ja rozumiem - sztuka dla sztuki.. ale jak dla mnie to jest to zwykłe utrudnianie, czy się mylę?

Może ja czegoś nie ogarniam, nie wiem - nie mam pojęcia.

[ohm]

To jest po prostu cały urok formularzy w sf2

[BigPig]

Hmm, do takich rzeczy lepiej użyć gotowych bundli. Za jednym razem masz rozwiązane: logowanie, zmiane hasla, rejestracje, odzyskiwanie hasla i cos tam jeszcze

https://github.com/FriendsOfSymfony/FOSUserBundle

Skoro masz zaczynać prace w sf2, to jestem na 99% pewny, że inni programiści też na tym pracują. Potem tylko dochodzi problem dostosowania bundla do swoich potrzeb, ale akurat ten ma świetną dokumentację, więc nie powinieneś mieć problemów

A co do dużej ilości nie potrzebnego kodu, to się zgodzę

Ten post edytował BigPig 21.10.2014, 21:17:59

[destroyerr]

Dokładnie jest tak jak piszesz: nie ogarniasz, nie wiesz i nie masz pojęcia.
Jeżeli tak bardzo chcesz to nic nie powstrzymuje Cię abyś sobie zrobił tego jednego ifa i będziesz super szybko i bez gmatwania. Jak już zarejestrujesz użytkownika i będzie chciał zmienić swoje dane to daj mu ten sam formularz z akceptacją regulaminu. Ewentualnie dodaj kolejnego ifa i po kłopocie.

Tam nie ma dwóch kontrolerów, tylko dwie akcje, jedna służy do obsługi GET a druga POST. No i pytanie który kod uznajesz za zbędny?

[by_ikar]

Utrudnianie? Czego dokładnie utrudnianie? Taki przykład można wygenerować w kilka minut, i jedynie potem dostosować to co wygenerowaliśmy do swoich potrzeb. Taki podziała właśnie jest czytelny (nie koniecznie trzeba lubić klasy generujące formularze). Najpewniej dopiero zaczynasz z obiektówką, stąd wydaje ci się że kodu jest za dużo, a wcale go dużo nie ma, nawet jakbyś miał to napisać z palca jest to maks kilkanaście min..

[Forti]

Utrudnianie? Czego dokładnie utrudnianie? Taki przykład można wygenerować w kilka minut, i jedynie potem dostosować to co wygenerowaliśmy do swoich potrzeb. Taki podziała właśnie jest czytelny (nie koniecznie trzeba lubić klasy generujące formularze). Najpewniej dopiero zaczynasz z obiektówką, stąd wydaje ci się że kodu jest za dużo, a wcale go dużo nie ma, nawet jakbyś miał to napisać z palca jest to maks kilkanaście min..

Po prostu mam porównanie z np. laraveler, gdzie jeden formularz generowałem w widoku, kontroler GET do jego wyświetlenia i kontroler POST to jego obsługi - to było "proste" i zwięzłe.

Tutaj mamy:
- klasę formularza w bundle/form/formType
- widok formularza w bundle/repository/view/form.html.twig
- kontroler POST/GET (ok - tutaj jest łatwiej)

dla mnie to troche przekombinowane Fakt - jeszcze nie do końca rozumiem symfony i tą logikę, dlatego przyszedłem z tym tutaj. Być może po prostu ktoś przytoczy lepszy argument niż "tak jest lepiej".

[destroyerr]

Symfony ma całkiem inną filozofię niż laravel więc nie mam pojęcia czemu to porównujesz.

[Forti]

Symfony ma całkiem inną filozofię niż laravel więc nie mam pojęcia czemu to porównujesz.

Nie porównuje frameworków samych w sobie (bynajmniej nie miałem takiego zamiaru) lecz rozwiązań pewnych kwestii. Faktem jest, że te frameworki bardzo od siebie się różnią

[destroyerr]

Po prostu mam porównanie z np. laraveler

Dobra, niech Ci będzie.

[by_ikar]

Po prostu mam porównanie z np. laraveler, gdzie jeden formularz generowałem w widoku, kontroler GET do jego wyświetlenia i kontroler POST to jego obsługi - to było "proste" i zwięzłe.

Tutaj mamy:
- klasę formularza w bundle/form/formType
- widok formularza w bundle/repository/view/form.html.twig
- kontroler POST/GET (ok - tutaj jest łatwiej)

dla mnie to troche przekombinowane Fakt - jeszcze nie do końca rozumiem symfony i tą logikę, dlatego przyszedłem z tym tutaj. Być może po prostu ktoś przytoczy lepszy argument niż "tak jest lepiej".

W symfony masz klasę do generowania całego formularza, w laravel nie tworzysz klasy formularza, tylko na poziomie widoku wyświetlasz poszczególne elementy które chcesz wyświetlić. I jest to trochę inne podejście do formularzy, co nie znaczy że w symfony nie mógłbyś zrobić formularza dokładnie tak samo. Bo dodaj jakąś walidacje, dodaj jakieś dodatkowe pola i wyjdzie na to samo..

PS nie różnią się aż tak bardzo, bo w wielu kwestiach są bardzo podobne, chociażby dlatego że laravel wykorzystuje cały httpkernel z symfony (plus kilka innych komponentów).

Ten post edytował by_ikar 23.10.2014, 07:44:27

[billy0o]

Tak to prawda, można to samo zrobić dużo prościej i szybciej:

[PHP] pobierz, plaintext 
    public function registerAction($request)
    {
        $data = array();
 
        $form = $this->createFormBuilder($data)
            ->add('email', 'text')
            ->add('password', 'password')
            // ...
            ->getForm();
         $form->handleRequest($request);
 
        if ($form->isValid()) {
            // przetwarzanie i warunki
        }
 
        return $this->render(
            'AcmeAccountBundle:Account:register.html.twig',
            array('form' => $form->createView())
        );
    }
[PHP] pobierz, plaintext 

Ale co jeśli chcemy użyć tego samego formularza w innej akcji? Np. w akcji dla urzadzeń mobilnych? No tak, tworzymy dodatkową funkcje prywatną kontrolera, przenosimy tam formularz i to się nazywa refaktoryzacja czyli proces, który zajmuje więcej czasu niż samo pisanie.

Ale idźmy dalej i okazuje się, że klient zażyczył sobie mini logowania jeszcze gdzieś indziej (w innym kontrolerze) i co sie dzieje? Tworzymy nową klasę z formularzem (!). Znów refaktoryzacja a po drodze mnóstwo błędów i bugów się rodzi a wraz z nimi ubywa włosów na głowie. A można by tego uniknąć po prostu stosując osobną klasę dla formularza na samym początku.

Model Registration jest oddzielony głównie ze względu na opis walidacji oddzielony od formularza, która niepotrzebnie by się plątała między definicjami pól. Poza tym operowanie na obiektach zawsze jest lepsze niż na surowych tablicach z danymi. Łatwo do takiego modelu dorobić np Captcha:

[PHP] pobierz, plaintext 
if ($registration->isCaptchaValid())
[PHP] pobierz, plaintext 

To zawsze nie tylko wygląda ale także lepiej funkcjonuje niż:

[PHP] pobierz, plaintext 
// .. initializowanie klasy captcha
if ($captcha->getValue() != $data['captcha'])
[PHP] pobierz, plaintext 

Oczywiście powyższy kod nie zginie, będzie w pliku Registration.php a nie w kontrolerze. Ale pamiętaj, ze im mniej w kontrolerze tym lepiej,dlatego, że kilka kontrolerów może korzystać z tej samej funkcjonalności.Po za tym im mniej logiki bliżej użytkownika tym bezpieczniej ale nie zamierzam tej tezy udowadniać

Im dłużej będziesz programować obiektowo tym bardziej przywykniesz do tego, że im więcej "zbędnego" opisowego kodu (równie komentarze są bardzo istotne, nawet jeśli pracujesz sam) tym lepiej w dłuższej perspektywie się pracuje. Również mnogość plików dla, wydawałoby się prostych funkcjonalności przestaje przerażać gdy kilka takich "rejestracji" przyjdzie nam rozbudować o nowe warianty, walidację czy inne ewentualności.

W przypadku takiej pojedynczej rejestracji masz rację - nie opłaca się kodu komplikować ale patrząc z perspektywy dłuższego utrzymania kodu wręcz ułatwiamy sobie zadanie od razu przygotowując go na rozbudowanie

Ten post edytował billy0o 23.10.2014, 23:25:39