2012-09-20 19 views
32

Tak więc, spodziewałem się Yeoman i jest już za jakiś tydzień. Ale po pomyślnym zainstalowaniu go, byłem zdezorientowany w przepływie pracy i implementacji za pomocą skryptu zaplecza (API).Yeoman Workflow and Integration with Backend Scripts

Scenariusz 1

Więc powiedzmy, że nie muszę te wszystkie błyszczące BBB/Ember/kątowa rzeczy i wykorzystywać Yeoman tylko dla jQuery/H5BP/modernizr łączona z CodeIgniter lub Sinatra/Rails. Od yeoman server nie natywnie obsługują PHP (nie próbowałem Sinatra/Rails), I zrozumieć, że pracy jest:

  • Front End Development z Yeoman
  • po jego zakończeniu, zrobić yeoman build a następnie użyj zbudowany dist folderu jako podstawa do opracowania backend (i prawdopodobnie skopiować folder dist do innego folderu na realizację backend (powiedzmy public folderu)
  • Jeśli miałbym zmienić CSS/JS, ponownie używać jako pisarza, zbudować i skopiować folder dist do public ponownie. Tak dalej ...

Ale za pomocą tego przepływu pracy, co oznacza, że ​​struktura katalogów będzie coś podobnego

cool-app/ 
--app/ 
    --yeoman development stuff 
--test/ 
    --yeoman development stuff 
--dist/ 
    --yeoman built stuff 
.dotfiles 
package.json 
Gruntfile.js 

jest to miła i wszystko, ale trochę inna z/Rails struktury katalogów CodeIgniter. Nie wspominając już o różnicach w nazwie (jest to konfigurowalny w Yeoman?), więc trudno jest wyobrazić sobie dobry przepływ pracy, który rozwija zarówno Front End, jak i Back End za jednym razem, z wyjątkiem użycia wbudowanego wyniku jako bazy dla backendu.

Scenariusz 2

BBB/Ember/kątowym. Szczerze mówiąc, właśnie testowałem te rzeczy, więc wszelkie wskazówki do wdrożenia z kodem zaplecza są mile widziane! Chociaż z tego, co wiem, yeoman może wygenerować niezbędne pliki dla tych frameworków w folderze aplikacji, więc sądzę, że rozwiązanie pierwszego scenariusza trochę rozwiąże problem dla scenariusza 2

Wielkie dzięki!

Odpowiedz

37

I jak za pomocą tej struktury:

rails-app/ 
--app/ 
    --views/ 
    --js/ 
     --app/ 
     --test/ 
     --Gruntfile.js 
--public 

Oto jak go ustawić:

  • szyn nowych szyn aplikacji
  • szyny-app cd/app/views
  • mkdir js
  • cd js
  • inicjatywa dla yomanów ember

Następnie edytować Gruntfile.js zmienić "Wyjście: 'dist'" na "wyjście: '../../../public'"

Po tym, "Yeoman build" lub " yeoman build: dist "wyświetli się w folderze Rails/public.

Podczas pracy dewelopera nadal można używać "serwera yomanów" do uruchamiania języka w trybie programowania, więc wszelkie wprowadzone zmiany będą automatycznie widoczne w przeglądarce.

Yeoman jest świetny!

3

Odpowiedź Sanforda również będzie działała dla Sinatry, ale istnieje nieco inne rozwiązanie, którego można użyć, aby nie trzeba było tworzyć "kompilacji", aby uruchomić ją w trybie programowania.

W Sinatry, folder publiczny jest konfigurowalny, dzięki czemu można mieć blok konfiguracyjny, który wygląda tak:

configure do 
    set :public_folder, ENV['RACK_ENV'] == 'production' ? 'dist' : 'app' 
end 

Następnie użyj swoje trasy tak:

get '/' do  
    send_file File.join(settings.public_folder, 'index.html') 
end 

to przy założeniu, że "yeoman init" został uruchomiony w folderze głównym aplikacji Sinatra.

Wszystko, co musisz zrobić, to upewnić się, że uruchomiłeś "kompilację yomana" przed wdrożeniem w środowisku produkcyjnym, a użyte zostaną materiały zoptymalizowane pod kątem języka.