2012-12-30 14 views
15

Czy istnieje dobry samouczek lub dokument Ember.js opisujący strukturę katalogów dla modeli/widoków/kontrolerów, app.js i sposób odniesienia się do tych plików w pliku głównym index.html.Struktura katalogu projektu Ember.js

  • Plik do utworzenia "Ember.Application.create"?
  • kolejność włączania (models.js, apps.js, controllers.js)?

Odpowiedz

2

Nadal wydaje się być oczywiste, konwencja, ale obecnie wielu ludzi wydaje się być za pomocą Yeoman i oficjalny generator Ember https://github.com/yeoman/generator-ember

Choć doceniam „otwarty” charakter ćwiczeń Ember, jedna z miłych rzeczy o Railsach jest konwencją umieszczania plików. Kiedy zatrudniamy nowego programistę, nie musimy wyjaśniać naszej struktury katalogów ... Mam nadzieję, że Ember wkrótce ustanowi oficjalny standard.

4

This tutorial by Dan Gebhardt był dla mnie bardzo pomocny przy tworzeniu mojej struktury projektu i zastanawianiu się, jak dołączyć pliki.

+1

+1. Bardzo podoba mi się ta struktura. Moim zdaniem jest znacznie lepiej dla średnich i większych aplikacji niż zaakceptowana odpowiedź, która prawdopodobnie szybko stanie się chaotyczna. – Nic

4

Ma rozsądny przykład układu projektu dla potoku rake. Robią to mniej więcej tak (from the README):

 
ember-skeleton 
├── Assetfile - App build file 
├── Gemfile - Package dependencies for rakep/rack 
├── Gemfile.lock - Here be dragons: don't touch, always include 
├── app - App specific code 
│ ├── css - App CSS or SCSS (.scss) 
│ ├── lib - App code, *modularized during build* 
│ ├── modules - Module code, *already modularized* 
│ ├── plugins - Plugins (e.g. jquery.jsonrpc.js) 
│ │ └── loader.js - JS module loader 
│ ├── static - Static files, never touched, copied over during build 
│ ├── templates - Handlebars templates, *modularized during build* 
│ ├── tests - QUnit application tests 
│ └── vendor - Vendor code, *modularized during build* 
├── assets - Built out asset files, minified in production 
│ ├── app.css - Built out app CSS/SCSS 
│ ├── app.js - Built out app JS 
│ └── loader.js - Built out JS module loader 
├── config.ru - Rack development web server configuration 
├── index.html - The app entry point 
├── tests - QUnit testing files 
│ ├── index.html - The testing entry point 
│ ├── qunit - Testing support files 
│ └── run-tests.js - The PhantomJS QUnit test runner 
└── tmp - Temporary build files used by rakep 
4

Mam układ, że jestem całkiem zadowolony z

app.js - to jest główny plik aplikacji i zawiera ustawienia i routera

views.js - zawiera widoki używane w aplikacji, choć zwykle to teraz podzielić się homeView.js navigtaionView.js itp

dataModels.js - to gdzie trzymam wszystkie moje model danych obiektów dla aplikacji

dataSources.js - używam tego, aby załadować datamodels lub tablice datamodels od jakichkolwiek wywołań API robię

accountController.js - klasa kontrolera, w załączonej próbki Mam też emailMessagingController oraz smsMessagingController

można znaleźć tu mój przykładowy projekt

https://github.com/bwship/neptunejs

i coffeescript pliki dla węgielek tutaj

https://github.com/bwship/neptunejs/tree/master/public/coffeescripts

i ostatecznie plik jad dla układu i wskaźnik pokazujący jak dodać te tutaj

https://github.com/bwship/neptunejs/tree/master/views

chcę, aby w końcu zacząć używać styl danych ember, ale zgasić kilka solidne aplikacje korzystające z plików dataSources i dataModels.

+0

Powiedziałbym, że jest to dobry punkt wyjścia dla mniejszych aplikacji.Jednak wydaje mi się, że to dość szybko staje się chaotyczne, jeśli chcesz zbudować większe aplikacje i podzielić je na osobne pliki modelu/widoku/kontrolera/szablonu, to byłoby to lepsze rozwiązanie. – Nic

+0

Tak, zdecydowanie. Konfiguruję go na większych projektach z aplikacjami, kontrolerami, modelami, trasami i folderem widoków z osobnymi plikami dla każdego. A następnie folder szablonów z szablonami kierownicy. – WallMobile

Powiązane problemy