Użyszkodnicy, czyli o co walczymy w każdym projekcie cz.I

Zgodnie z zapowiedziami przyszedł czas na bardziej zaawansowane rzeczy w Grails. Myślę, że HowToJava jest gotowe na przyjęcie pierwszych użytkowników.

Zagadnienie zarządzania uzytkownikami każdej aplikacji internetowej to tzw. core, czyli element należący do rdzenia aplikacji, który po napisaniu podlega raczej niewielkim modyfikacjom. Dlatego też tym bardziej trzeba ten temat przemyśleć. Z całą pewnością kwestię użytkowników trzeba wpierw podzielić na 2 ‘fronty’ – backend i frontend.

Backendem w tym przpadku nazywam zarządzanie użytkownikami poprzez administrację lub automatyczne działania kodu. Czyli po rejestracji takowy kod wyśle mejla aktywującego, albo też wyświetli moderatorowi dane delikwenta, który pragnie zarejestrować się w serwisie. Z kolei frontend to wszystko to, co może zrobić użytkownik ze sobą (zarówno ten niezarejstrowany, jak i z pełnią praw w serwisie). Nie jest to podział intuicyjny, ani też taki, który da się wyczytać w necie. Jednakże dobrze oddaje kroki, które po kolei będę wykonywał, aby zaimplementować funkcjonalność w serwisie.

Wyjdźmy od modelu. Bardzo to trąci DDD, o którym w kontekście całości Grailsów z pewnością kiedyś napiszę. Jednakże to, że trąci wcale nie oznacza, że to źle! Dobra, bo zabieram się jak do zabicia karpia 🙂 Oto co trzeba na pewno w aplikacji:

  • proces rejestrowania uzytkowników, a w nim:
    • formularz rejestracji, jego walidacja oraz zapis do bazy
    • poinformowanie użytkownika o powodzeniu/niepowodzeniu procesu rejestracyjnego ( e-mail, komunikaty na stronie zaraz po rejestracji)
  • stworzenie namiastki panelu administracyjnego, który pozwoli na zarządzanie użytkownikiem (zarówno w procesie rejestracji jak i jego dalszej działalności)
  • napisanie kodu, który obsłuży użytkownika po zalogowaniu na stronie (do tego oczywiście oddzielna funkcjonalność oparta na formularzu rejestracji), a konkretnie:
    • rejestracja użytkownika w zasięgu sesji aplikacji
    • zbudowanie mniej lub bardziej rozbudowanego ACLa
    • stworzenie funkcjonalności, w której użytkownik będzie mógł się poruszać (czyli reszty serwisu)

Jak już wcześniej wspomniałem piszę kolejne notki na bieżąco, zatem powyższa lista z pewnością jest niekompletna i ulegnie modyfikacjom. Da się jednakże zauważyć oczywistą rzecz – potrzebujemy na pewno stworzyć kod, który będzie reprezentował naszego użytkownika (lub kandydata na niego). Nie zamierzam póki co bawić się w bardziej zaawansowane rzeczy – rejestracja zatem będzie przebiegała po prostu poprzez wpisanie nicku (unikatowego), a także hasła (plus potwierdzenie), dodamy także delikatną CAPTCHE, aby spamerzy nie mieli zbyt łatwo. Antycypując kolejne kroki nadamy też każdemu użytkownikowi jakąś rolę, którą będzie miał w serwisie – na szybko będą to role pod tytułem ‘czytacz’, ‘zwykły user’ i ‘admin’ (to ja :). Oto klasa dziedzinowa dla użytkownika:

class Htj_Users {

    static mapping = {
        id column: 'user_id'
    }

     static constraints = {
         nick( blank: false, size: 5..40, nullable: false, unique: true )
         passwd(blank: false, maxSize: 32, nullable: false, password: true )
         role( blank: false, nullable: false )
     }

    String nick;
    String passwd;
    Htj_User_Role role;
}

No i oczywiście mikroskopijna klasa dla typu roli:

class Htj_User_Role {

  static mapping = {
      id column: 'role_id'
  }

  String role_name;
}

Tworzymy kontroler o wdzięcznej nazwie UserController. Wpisujemy do niego taki kod:

def scaffold = Htj_Users;

i można już pobawić się dzięki scaffoldingowi. Ja do bazy przez PMA dodałem tylko trzy kategorie (wcześniej wymienione) i jak zawsze rusztowanie pozwala rozeznać się czy wszystko gra. Póki co gra zatem na dziś to koniec, późno trochę. Następnym razem zaimplementujemy cały CRUD ‘z palca’ plus zainstalujemy i wykorzystamy pierwszy raz plugin do frameworka.

Advertisements

3 thoughts on “Użyszkodnicy, czyli o co walczymy w każdym projekcie cz.I

  1. Marek Podsiadły

    Jak czytam Twoje kody, to strasznie drażni mnie nazewnictwo klas, odbiega od standardów javowych. Powinno być HtjUserRole zamiast Htj_User_Role

  2. chlebik Post author

    Takie przyzwyczajenie z autoloadera klas w Zend Framework, gdzie podkreslniki oznaczaja kolejny katalog/plik. Jesli znasz jakis ciekawy tutorial/HOWTO o coding standards w Javie to z checia poczytam.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s