Jeżeli tworzymy kilka aplikacji w ruby on rails, to przeważnie początkowe etapy są do siebie bardzo podobne. Np. inicjalizacja kontroli wersji (np. w sposób jaki jest opisany w poprzednim artykule), instalacja ulubionych pluginów, usuwanie zbędnych plików, Czy też inne operacje. Na szczeście do pomocy przychodzą nam Templates, które zostały wprowadzone w rails 2.3. Teplate to nic innego niż plik ruby, w którym wpisujemy komendy w przygotowanym do tego języku domenowym (DSL). Po przygotowaniu takiego szablonu inicjujemy projekt rails z parametrem -m ścieżka_do_szablonu.rb
. Rails od razu po wykonaniu inicjacji projektu od razu uruchomi podany plik.
1 |
rails my_app -m ~/szablon_startowy.rb |
tak samo jak URI, możemy uzywać URL:
1 |
rails my_app -m http://marioosh.5dots.pl/szablon.txt |
(powyższy plik nie istnieje więc nie testujcie ;) )
ostatnim sposobem jest inicjacja szablonu przed odpowiednie zadanie rake
z ustawienie zmiennej LOCATION
:
1 |
rake rails:template LOCATION=~/szablon_startowy.rb |
Jakie operacje możemy wykonywać w przygotowanym języku DSL? Może zacznemy od przykładu.
Zacznijmy od wykonania kilku operacji opisanych w poprzednim artykule, mówiącym o wprowadzeniu aplikacji rails pod kontrolę Git.
Przygotujmy nasz plik szablonu, ja go utworzłem w katalogu domowym i zapisałem go jako 5dots_template.rb
Kroki które powinniśmy wykonać:
- inicjalizacja Git,
- utworzenie pliku .gitignore w folderach
tmp
ilog
- dodaniu kilku wpisów w głównym
.gitignore
.
Plik powinien wyglądać tak:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# 5dots_szablon.rb git :init git :add => "." # teraz dodajemy pliki .gitignore do folderów tmp i log. run "touch tmp/.gitignore log/.gitignore" #oraz tworzymy plik .gitignore w głównym folderze z zawartością: file '.gitignore', <<-GITIGNORE_FILE .DS_Store log/*.log tmp/**/* config/database.yml db/*.sqlite3 doc/app doc/api GITIGNORE_FILE # teraz pozostaje tylko zatwierdzenie zmian do repozytorium: git :commit => "-a -m 'Initial commit'" |
W powyższym przykładnie poznaliśmy kilka komend języka DSL dla szablonów, wyjaśniam po kolei:
– git
odpowiada za komendy systemu kontroli wersji git,
– run
uruchamia polecenia konsolowe.
1 |
run "rm -rf *" |
(komenda ta robi porządki w folderze :) )
– file
– odpowiada za tworzenie plików i operacje na nich.
Mając podstawy za sobą możemy przejść do szczegółowego opisania wszystkich poleceń, w końcu te trzy powyższe, może i zrobią dużo, to i tak nie wszystko.
Polecenie rake
Za wykonywanie zadań rake jest odpowiedzialna komenda o tej samej nazwie ,dodatkowo możemy uruchomić skrypt jako superużytkownik, wtedy musimy podać parametr :sudo => true
. Dodatkowo możemy podać parametry, których możemy używać podczas ręcznego użycia komendy rake
.
1 2 3 4 5 |
rake "gem:install" # lub jako superuser rake "gem:install", :sudo => true # jeszcze jeden przykład: rake "gem:install", :env => 'production' |
Operacje na gemach
Komenda gem
odpowiada za dodawanie gemów. Komenda dodaje odpowiedni wpis do pliku config/envoirnment.rb
. Parametry, które mają być również dopisane (takie jak :version, :lib, :source
) podajemy na końcu.
Komenda nie istaluje gema, do tego celu musimy użyć odpowiedniego zadania rake (zgadnijcie którego :) )
Kilka przykładów:
1 2 3 |
gem 'thoughtbot-factory_girl', :lib => 'factory_girl', :source => 'http://gems.github.com' gem "hpricot", :version => '0.6', :source => "http://code.whytheluckystiff.net" gem "RedCloth" |
Instalowanie wtyczek (inaczej zwanymi pluginami) :)
Aby zainstalować pluginy używamy z komendy plugin
(mam wrażenie, że się domyślaliście – ot taki prosty ten język, wszystko jest domyślnie proste)
Pluginy możemy instalować z svn, z gita lub z gita jako submoduły:
1 2 3 4 5 6 |
# instalowanie ze starego dobrego subversion: plugin 'svnowy_plugin', :svn => 'svn://repozytorium/scieżka_do_plugina/trunk' # albo z nowego, jeszcze lepszego gita: plugin 'git_plugin', :git => 'git://github.com/scieżka_do_plugina.git' # lub nawet jako submoduł gitowy (o tym będzie w następnym artykule) plugin 'git_plugin', :git => 'git://github.com/scieżka_do_plugina.git', :submodule => true |
Inicjalizery- czyli automatory, wewnątrz automatora :)
Jeżeli korzystamy z inicjalizerów, czyli skryptów, które są uruchamiane podczas startu aplikacji używamy komendy initialize
. Właśnie ona, tworzy plik w folderze cofnig/initializers
1 2 3 4 5 6 7 8 |
initialize "nowy_object.rb", <<NOWY_OBJECT_CONTENT class Object def nowa_metoda puts "Fajna ta nowa metoda, dobrze, że mogę z niej korzystać, zanim railsy się odpalą! "; end end NOWY_OBJECT_CONTENT |
Dokładnie na tej samej zasadzie działają komendy lib
i vendor
, które tworzą pliki w folderach (odpowiednio) /lib
i /vendor
.
Pliki
Tworzenie nowych plików tworzymy na podobnej zasadzie jak poprzednia metoda, główną różnicą jest, że plik zostanie utworzony, wg folderu RAILS_ROOT a nie wewnątrz initailizers
.
1 2 3 4 5 |
file "app/components/Klasa.rb", <<KLASA class Klasa end KLASA |
Komenda powyższa utworzy foldery app/components
i umieści w nim plik Klasa.rb
.
Zadania Rake
Komenda rakefile
tworzy plik w folderze /lib/tasks
1 2 3 4 5 6 7 |
rakefile "clear_all.rake" do namespace :clear do task :all do puts "Usuwamy wszystko!!!!! " end end end |
Teraz to zadanie możemy uruchomić po wydaniu komendy: rake clear:all
.
Generatory
Generatory możemy uruchomić komendą generate
i podając listę argumentów. Możemy uzywać wszystkie generatory, które są standardowo w railsach, lub które uprzednio zainstalowaliśmy w formie pluginów lub gemów.
1 2 |
generate(:scaffold, "person", "name:string", "email:string", "password:string" generate("rspec") |
Uruchamianie skryptów powłoki
Jak już wspomniałem można tego dokonać za pomocą komendy run
1 |
run "rm -rf *" |
Dodawanie rutingów :)
Jeżeli potrzebujemy dodatkowych wpisów w pliku /config/routes.rb
wykonujemy je uruchamiając komendę route
1 |
route "map.root :controller => :person" |
Zmiana folderu
Czasami wygodne jest przejście do innego folderu i w nim wykonanie kilku operacji, możemy to zrobić za pomocą komendy inside
. Jako parametr podajemy folder docelowy i potem block.
1 2 3 4 5 |
inside "config" do run "cp database.yml database.orig.yml" # linkowanie ustawień z innego projektu, bo oba mają działać na tej samej bazie run "ln -s /projekty/super_rails_app/config/database.yml database.yml" end |
Działanie zależne od odpowiedzi
Podczas wykonywania skryptu, możemy wprowadzić małą intekerakcję, np. zadać pytanie i zależnie od odpowiedzi wykonać dalej skrypt.
Na przykład możemy zapytać o nazwę pliku. W tym celu wykonujemy komendę ask
.
W poniższym przykładzie pytamy sie o nazwę pliku dla pliku konfiguracji .yml
. Skrypt również sprawdza, czy rozszerzenie zostało podane czy nie. jeżeli nie, to dodaje je do nazwy pliku.
1 2 3 4 5 6 7 8 9 |
file_name = ask("Podaj nazwę pliku konfiguracyjnego") file_name << ".yml" unless file_name.index(".yml") file "/config/" << filename, <<FILE_CONTENT global_settings: color: #e343f3 font-size: 14px FILE_CONTENT |
Istnieją również uproszczone wersje powyższej metody, jedna oczekuje na odpowiedź „yes” druga na „no”
1 2 3 4 5 6 7 8 9 |
gem "RedCloth" if yes?("Zainstalować gem Red Cloth?") if no?("Zainstalować gem Blue Cloth?") gem ask("Podaj nazwę gemu z edytorem, którym ma być użyty zamiast BlueCloth:") else gem "BlueCloth" end # po wpisaniu 'no' zostanie uruchomione zapytanie o nazwe gem'a, w każdej innej sytuacji zostanie dodany BlueCloth |
GIT – kochaj albo rzuć :)
Komenda git
wykonduje komendy systemu kontroli wersji Git – jak nie trudno się domyśleć.
1 2 3 4 |
git :init git :add => "." git :commit => "-a -m 'Initial commit'" git :submodule => "init" |
Rezume :P
Lista komend do wykorzystania:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
gem(nazwa, options={}) plugin(nazwa, options={}) initializer(nazwa_pliku, data=nil, &block) lib(nazwa_pliku, data=nil, &block) vendor(nazwa_pliku, data=nil, &block) rakefile(nawa_pliku, data=nil, &block) generate(co_generować, argumenty) run(komenda) rake(komenda, options={}) route(routing_code) inside(folder) ask(pytanie) yes?(pytanie) no?(pytanie) git(parametry) |
Teraz znająć już wszystkie komendy, możemy tworzyć własne szablone jako startowe ustawienia aplikacji. Jeżeli stworzymy coś nowego i fajnego warto się tym podzielić. Moża dodać je do projektu: Rails Templates, który takie szablony zbiera. Możemy również skorzystać z instniejących tam szablonów.
.