« W najbliższą sobotę (18.8) Bootstrap 7.8
Bootstrap 7.10 już za tydzień (20.10.2007). »

Jeszcze szybsze prototypowanie w Railsach? Hobo!

Pewnie wiesz lub słyszałeś/-aś jak szybko tworzy się prototypy w Ruby on Rails. Znasz pewnie generator “scaffold_resource” gdzie możesz z linii poleceń stworzyć model, migracje, pełen CRUD (controller i widoki) i to w wersji RESTful. Dodatkowo dostajemu podstawowe API (XML) do zarządzania tym modelem.
Przykład:

ruby script/generate scaffold_resource Person first_name:string last_name:string notes:text

Nie będę opisywał jak dokładnie wyglądają wygenerowane pliki ponieważ to możecie sprawdzić sami.

Część was znudzona pisaniem własnych paneli administracyjnych pewnie znalazła takie projekty jak ActiveScaffold czy auto-admin (klon rozwiązania z Django) ew nawet Streamlined (muszę przyznać, że moja wiedza o tym projekcie jest ograniczona).

Są to faktycznie niezłe rozwiązania konkretnego problemu - panelu administracyjnego (może z wyłączeniem Streamlined, który idzie w inną stronę).
Na pierwszy rzut oka Hobo służy do rozwiązywania tego samego problemu - błąd.
Jako zachętę do dalszego czytania polecam te 3 screencasty.

Zaznaczam aby nie próbować tworzyć aplikacji razem z prowadzącym - za chwilę wyjaśnię dlaczego.

Krótki? wstęp do Hobo

Dla leniwych kod aplikacji dostępny jest w pliku załączonym do tego wpisu

Kod jest zgodny z wersją 0.6.2 i może przestać działać w wersjach wyższych od tej.

Do rozpoczęcia pracy nad projektem wystarczy wygenerować modele i je odpowiednio zdefiniować.

Instalujemy Hobo:

sudo gem install hobo

Tworzymy nowy projekt. Jest to projekt Railsowy z modyfikacjami Hobo:

hobo blog

Hobo stworzył nam modele User oraz Guest, kontrolery Application, Front i User

W katalogu głównym projektu tworzymy modele:

ruby script/generate hobo_model Post
ruby script/generate hobo_model Comment

i kontrolery tych modeli:

ruby script/generate hobo_model_controller Post
ruby script/generate hobo_model_controller Comment

Teraz możemy zająć się definicjami modeli. Poza standardowymi definicjami relacji mamy blok fields
Uważni zauważyli pewnie, że generator modeli nie tworzy plików migracji, zostaną one wygenerowane automatycznie wraz z określeniem pól w bloku filelds. W tym bloku poza standardowymi typami Railsowymi mamy takie typy jak :html, :markdown, jeżeli uzupelnimy blok o wpis timestamps stworzone zostaną pola created_at i updated_at.
Jeżeli odpowiednio zdefiniujesz relacje odpowiednie pola dla kluczy zostaną stworzone. Hobo będzie również śledził zmiany w polach i odpowiednio modyfikował pola w migracjach.
W tym bloku możemy również definiować walidatory.

Załóżmy że nasze proste modele wyglądają tak:

Code (ruby)
  1.  
  2. class Post < ActiveRecord::Base
  3.  
  4.   hobo_model
  5.  
  6.   fields do
  7.     title :string
  8.     content :html
  9.   end
  10.  
  11.   belongs_to :user
  12.   has_many :comments
  13.  
  14.   # — Hobo Permissions — #
  15.  
  16.   def creatable_by?(user)
  17.     false
  18.   end
  19.  
  20.   def updatable_by?(user, new)
  21.     false
  22.   end
  23.  
  24.   def deletable_by?(user)
  25.     false
  26.   end
  27.  
  28.   def viewable_by?(user, field)
  29.     true
  30.   end
  31.  
  32. end
Code (ruby)
  1. class Comment < ActiveRecord::Base
  2.  
  3.   hobo_model
  4.  
  5.   fields do
  6.     content :html
  7.   end
  8.  
  9.   belongs_to :post
  10.   belongs_to :user
  11.  
  12.   # — Hobo Permissions — #
  13.  
  14.   def creatable_by?(user)
  15.     false
  16.   end
  17.  
  18.   def updatable_by?(user, new)
  19.     false
  20.   end
  21.  
  22.   def deletable_by?(user)
  23.     false
  24.   end
  25.  
  26.   def viewable_by?(user, field)
  27.     true
  28.   end
  29.  
  30. end
Code (ruby)
  1. class User < ActiveRecord::Base
  2.  
  3.   hobo_user_model :username
  4.  
  5.   fields do
  6.     username :string
  7.     timestamps
  8.   end
  9.  
  10.   has_many :posts
  11.   has_many :comments
  12.  
  13.   alias_attribute :to_s, :username
  14.  
  15.   # — Hobo Permissions — #
  16.  
  17.   def super_user?
  18.     # Return true to make this user exempt from permission restrictions
  19.     # e.g.
  20.     # login == ‘admin’
  21.   end
  22.  
  23.   def creatable_by?(creator)
  24.     false
  25.   end
  26.  
  27.   def updatable_by?(updater, new)
  28.     false
  29.   end
  30.  
  31.   def deletable_by?(deleter)
  32.     false
  33.   end
  34.  
  35.   def viewable_by?(viewer, field)
  36.     true
  37.   end
  38.  
  39.   # — Fallback permissions — #
  40.  
  41.   # (Hobo checks these for models that do not define the *_by? methods)
  42.  
  43.   def can_create?(obj)
  44.     false
  45.   end
  46.  
  47.   def can_update?(obj, new)
  48.     false
  49.   end
  50.  
  51.   def can_delete?(obj)
  52.     false
  53.   end
  54.  
  55.   def can_view?(obj, field)
  56.     true
  57.   end
  58.  
  59. end

W tym momencie musimy jeszcze określić dane do logowania w config/database.yml
Jeżeli mamy zainstalowaną obsługę SQLite3 wystarczy:

development:
  adapter: sqlite3
  database: db/blog_development.db

Generujemy migracje.

ruby script/generate hobo_migration

migracja zostanie wyrzucona na ekran konsoli, wciskamy m i ewentualnie podajemy nazwę pliku migracji (lub wciskamy Enter by pozostawić proponowany).

W tym momencie pozostało nam jesze wykomentować linię

Code (ruby)
  1. #protect_from_forgery # :secret => ‘800307a1978ce41fd085febace050fd7′

w app/controllers/application.rb, która może sprawiać nam problemy (nowe zabezpieczenia w Edge Rails z tego co wyczytałem).

Odpalamy

ruby script/server

i pod adresem http://localhost:3000/ powinniśmy mieć działającą aplikację Hobo-Railsową :)

Przetestujmy czy działa - w przeglądarce wchodzimy na http://localhost:3000/signup powinien pojawić się formularz zakładania nowego konta. Załóżmy użytkownika o nazwie admin (to dość ważne by użyć tego loginu dla dalszej części tego poradnika).
W celu późniejszego zalogowania się do aplikacji używamy http://localhost:3000/login

Możemy poruszać się po naszym nowym blogu ale przyznajmy to szczerze “wieje nudą” bo nie możemy nic dodać ani edytować - zmieńmy to.

W modelu User przedefiniujemy metodę super_user? by wyglądała tak:

Code (ruby)
  1. def super_user?
  2.     # Return true to make this user exempt from permission restrictions
  3.     # e.g.
  4.      login == ‘admin’
  5.   end

To sprawia, że nasz użytkownik jest administratorem i został wyłączony z restrykcyjnego w tym momencie systemu uprawnien.
Pobawmy się aplikacją w tym momencie. Jak widać wszystko działa pięknie, cała edycja jest w standardzie Ajaxowa. Do wyświetlania na listach używane jest pole name lub title jeżeli takie pole nie występuje brana jest nazwa modelu + id. Możemy to zmienić definiując metodę to_s dla danego modelu.

W ten sposób w dosłownie 5 minut mamy działającą aplikację. W tym momencie możemy zająć się modyfikacjami widoków (a dokładniej ich stworzeniem) np app/views/posts/show.dryml
Sprawmy by ten plik wyglądał tak:

<Page>
<main>
<panel>
<header><h2>Wpis na blogu</h2></header>
<section>
Tytuł: <editor:title/>
</section>
<section>
Treść: <editor:content/>
</section>
<section>
Komentarze: <view:comments part=”post_comments”/><br />
</section>
<section>
Użytkownik: <editor:user/><br />
</section>
</panel>
<form with=”&Comment.new” update=”post_comments, comment_form” part=”comment_form”>
<input:content/>
<input:user/>
<input:post/>
<submit label=”Dodaj”/>
</form>
</main>
</Page>
Kilka słów wyjaśnienia. W tym przypadku jesteśmy w kontekście konkretnego Posta/Wpisu na blogu i polecenieeditor “wie”, że chodzi o edycję pola w obrębie tego obiektu. Możemy ten kontekst oczywiście zmieniać dla określonej części kodu.
Jeżeli zalogowany użytkownik nie ma uprawnień do edycji danego obiektu lub danego pola zamiast edytora pojawi się po prostu view chyba, że użytkownik nie będzie miał uprawnień do oglądania obiektu/pola.

Przez part definiujemy części strony, które później możemy podawać jako parametr do Ajaxowych przeładowań. Gdybyśmy w deklaracji formularza wyżej pominęli updates formularz odesłałby nas do strony nowo stworzonego posta a tak po jego dodaniu odświeży nam komentarze i sam formularz.

System autoryzacji.

Hobo umożliwia nam korzystanie z wielu niezależnych modeli do obsługi użytkowników. Standardowo tworzy model User ale możemy również stworzyć własne, które będą koegzystowały ze sobą (np Admin czy Editor) i będą zdefiniowane zupełnie odrębnie.

Hobo umożliwia też proste wpięcie zaawansowanego systemu autoryzacji (np authorization plugin- odpowiednie metody maja tylko zwrócić true lub false.

Konkrety - dlaczego moim zdaniem Hobo jest tak ciekawe i ma szansę stać sie bardzo popularnym projektem.

  • wysoki poziom abstrakcji w DRYML
  • przygotowany rozsądny schemat pod system autoryzacji
  • wbudowany i działający z “pudełka” mechanizm autentykacji
  • DRYML w bardzo przyjemny sposób wykorzystuje AJAX
  • całość utrzymywana w podejściu REST
  • możliwość modyfikacji wszystkich widoków
  • bardzo szybko otrzymujemy gotową i działającą aplikację i musimy się skupić na tym co dla nas najważniejsze
  • gdy potrzebujemy możemy ominąć Hobo i działać w “normalnych” Railsach
  • wbudowany mechanizm wyszukiwania
  • definiowanie własnych, złożonych tagów

Co twórcy Hobo muszą moim zdaniem nadrobić jeżeli chcą by projekt zyskał sporą popularność.

  • tworzyć dokumentację! W tym momencie 80-90% z dostępnej dokumentacji (włączając w to screencasty) jest nieaktualna (kod tam zawarty po prostu nie działa)
  • pracować nad wydajnością - w tym momencie Hobo nadaje się do tworzenia niewielkich aplikacji - najlepiej intranetowych - tu oczywiście wchodzi w grę narzut z racji tak wysokiego stopnia abstrakcji
  • niestety ale marketing - trafiłem na ten projekt przypadkiem a moim zdaniem powinien być zestawiany wśród najciekawszych Railsowych projektów

Mam nadzieję, że zainteresowałem was choć trochę Hobo i poświęcicie mu trochę czasu gdy wejdzie w fazę stabilna i pojawi się konkretna dokumentacja.

Wydaje mi się, że twórcy Hobo zebrali najlepsze pomysły z Ruby on Rails i Django i próbują zrobić coś co wychodzi jeszcze o krok dalej. Trzymam kciuki i będę śledził dzieje tego projektu.

Hobo Blog - aplikacja stworzona na potrzeby tego wpisu

This entry was posted on Monday 1. October 2007 at 16:16 and is filed under: django, ruby on rails, ruby, framework, prototyp, hobo. You can follow any responses to this entry through RSS. | Trackback URI.

One Response to

  1. Hobo 0.7 i dokumentacja. « Adam Hościło on pyPla.net via Pingback:
    30. January, 2008 at 07:51

    […] Przypominam, że pisałem o Hobo tu: http://hoscilo.pypla.net/2007/10/01/jeszcze-szybsze-prototypowanie-w-railsach-hobo/ […]

Leave a Reply »

Sirius Theme by Olaf A. Schmitz - Adam Hościło on pyPla.net is powered by WordPress (WP.de) - Login