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

[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ć (IMG:style_emoticons/default/smile.gif)

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 (IMG:style_emoticons/default/smile.gif)

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