attr_accessor jest świetne (szczególnie jeżeli ktoś przychodzi do Rubiego np. z Javy), ale ma jedną zasadniczą wadę - nazwa zmiennej instancji == nazwa metody (settera i gettera). W 99% to bardzo dobrze, ale dla tego jednego procenta powstało named_accessors.
Mam nadzieję że komuś się kiedyś przyda :)
Pokazywanie postów oznaczonych etykietą gem. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą gem. Pokaż wszystkie posty
czwartek, 16 lutego 2012
poniedziałek, 23 stycznia 2012
param_protected i Devise
Kilka dni temu pisałem już o gemie param_protected. Jeżeli używamy go razem z Devise, będziemy musieli zrobić zmodyfikować kontrolery i dodać definicję dozwolonych parametrów.
Po pierwsze musimy zmapować URL-e na nasze nowe kontrolery.
Po pierwsze musimy zmapować URL-e na nasze nowe kontrolery.
sobota, 14 stycznia 2012
param_protected wycina potrzebne parametry
param_protected to świetny gem, który przenosi funkcjonalność attr_accessible oraz attr_protected do kontrolerów. Składnia jest bardzo prosta:
Jedyny problem jest taki, że nie ma defaultowej listy dozwolonych parametrów. Tzn. że wycinane są takie atrybuty jak action, controller, id, utf8 czy (w przypadku używania devise) authenticity_token. Formularze nie będą przez to działać poprawnie, będziemy cały czas wylogowywani itd.
Jedyny problem jest taki, że nie ma defaultowej listy dozwolonych parametrów. Tzn. że wycinane są takie atrybuty jak action, controller, id, utf8 czy (w przypadku używania devise) authenticity_token. Formularze nie będą przez to działać poprawnie, będziemy cały czas wylogowywani itd.
czwartek, 5 stycznia 2012
Capybara i Devise - mock logowania
Piszemy request spec-i dla naszej aplikacji.
No i problem! Jak zalogować użytkownika?
No i problem! Jak zalogować użytkownika?
środa, 14 grudnia 2011
Mongoid: polimorficzne embeds_one
Nie da się
Załóżmy, że nasza aplikacja ma model MediaObject, który posiada tytuł, głosy itd. ale specyficzne informacje n/t obiektu (treść/link etc.) są w innym modelu (Media::Text, Media::Image etc.). Relacja oczywiście jeden-do-jeden. Jeżeli zrobimy to na zasadzie referenced assosiation, czyli relacje rodem z baz SQL, będziemy mieli zawsze n+1 zapytań. Mongoid co prawda obsługuje eager loading, ale nie dla relacji polimorficznych. Co więc możemy zrobić?
Tworzymy model MediaObject:
Oraz model Media::Resource - po nim będą dziedziczyć wszystkie modele z modułu Media
Teraz możemy dodać np. model Media::Text
Użycie:
Żeby ułatwić sobie życie, możemy wydelegować #content do MediaObject
Opcja allow_nil pozwala trzymać w #content pustą wartość. W tym przypadku to bardzo ważne, bo nie wiemy czy napewno wszystkie modele Media będą miały taką metodę. Gdyby nie miały, bez tej opcji model zawrze rzucał by wyjątek. Teraz użycie wygląda tak:
Załóżmy, że nasza aplikacja ma model MediaObject, który posiada tytuł, głosy itd. ale specyficzne informacje n/t obiektu (treść/link etc.) są w innym modelu (Media::Text, Media::Image etc.). Relacja oczywiście jeden-do-jeden. Jeżeli zrobimy to na zasadzie referenced assosiation, czyli relacje rodem z baz SQL, będziemy mieli zawsze n+1 zapytań. Mongoid co prawda obsługuje eager loading, ale nie dla relacji polimorficznych. Co więc możemy zrobić?
Tworzymy model MediaObject:
Oraz model Media::Resource - po nim będą dziedziczyć wszystkie modele z modułu Media
Teraz możemy dodać np. model Media::Text
Użycie:
Żeby ułatwić sobie życie, możemy wydelegować #content do MediaObject
Opcja allow_nil pozwala trzymać w #content pustą wartość. W tym przypadku to bardzo ważne, bo nie wiemy czy napewno wszystkie modele Media będą miały taką metodę. Gdyby nie miały, bez tej opcji model zawrze rzucał by wyjątek. Teraz użycie wygląda tak:
Subskrybuj:
Komentarze (Atom)