ruby-on-rails-and-ember-cli
- 1. researchR Ruby on Rails + Ember-CLI ( and chrome )
- 2. Backend ( ruby on rails ) Basics: ● spin up a new rails app ● this will be our api ○ an application programming interface (API) ■ yay!
- 3. Backend ( ruby on rails ) for researchR: ● Needed models for Entries, Projects and Users o set-up controllers to serve up json
- 4. Backend ( ruby on rails ) for researchR: ● Serializers o set-up to serve your data
- 5. Backend ( ruby on rails ) for researchR: ● Using Devise for Auth o set-up Devise as you would normally o dont worry about exporting the views ( all this will be in the ui )
- 6. Backend ( ruby on rails ) for researchR: ● to connect the two o “Rack::Cors provides support for Cross-Origin Resource Sharing (CORS) for Rack compatible web applications”
- 7. frontend ( ember-cli) Basics: ● set up a new shiney ember-cli app
- 8. frontend ( ember-cli) for researchR: ● routes: each one represents a state in your app
- 9. frontend ( ember-cli) for researchR: ● controllers - controllers let you decorate models with display logic
- 10. frontend ( ember-cli) for researchR - these were not needed: ● views : “The role of the view in an Ember.js application is to translate browser events into events that have meaning”
- 11. frontend ( ember-cli) for researchR: ● models: “every route (... can have an ...) associated model. This model is set by implementing a route's model hook, by passing the model as an argument to {{link-to}}, or by calling a route's transitionTo() method”
- 12. frontend ( ember-cli) for researchR: ● templates: “Handlebars templates as an HTML-like ... for describing the user interface”
- 13. frontend ( ember-cli) for researchR: ● Authentication! o ember-cli-simple-auth to for the app and -auth-devise to hook up to devise in rails land
- 14. chrome extension for researchR: ● Need TO wrap it all together! o lucky for us Chrome makes it simple: 1- create a manifest file named manifest.json 2- add resources (must exist inside the extension package) 3- load unpacked extension 4- reload
- 15. Resources developer.chrome.com emberjs.com devmynd.com simplabs.com
Editor's Notes
- #9: To understand why this is important, imagine we are writing a web app for managing a blog. At any given time, we should be able to answer questions like: Is the user currently logged in? Are they an admin user? What post are they looking at? Is the settings screen open? Are they editing the current post? In Ember.js, each of the possible states in your application is represented by a URL. Because all of the questions we asked above— Are we logged in? What post are we looking at? —are encapsulated by route handlers for the URLs, answering them is both simple and accurate. To understand why this is important, imagine we are writing a web app for managing a blog. At any given time, we should be able to answer questions like: Is the user currently logged in? Are they an admin user? What post are they looking at? Is the settings screen open? Are they editing the current post? In Ember.js, each of the possible states in your application is represented by a URL. Because all of the questions we asked above— Are we logged in? What post are we looking at? —are encapsulated by route handlers for the URLs, answering them is both simple and accurate. To understand why this is important, imagine we are writing a web app for managing a blog. At any given time, we should be able to answer questions like: Is the user currently logged in? Are they an admin user? What post are they looking at? Is the settings screen open? Are they editing the current post? In Ember.js, each of the possible states in your application is represented by a URL. Because all of the questions we asked above— Are we logged in? What post are we looking at? —are encapsulated by route handlers for the URLs, answering them is both simple and accurate. To understand why this is important, imagine we are writing a web app for managing a blog. At any given time, we should be able to answer questions like: Is the user currently logged in? Are they an admin user? What post are they looking at? Is the settings screen open? Are they editing the current post? In Ember.js, each of the possible states in your application is represented by a URL. Because all of the questions we asked above— Are we logged in? What post are we looking at? —are encapsulated by route handlers for the URLs, answering them is both simple and accurate. To understand why this is important, imagine we are writing a web app for managing a blog. At any given time, we should be able to answer questions like: Is the user currently logged in? Are they an admin user? What post are they looking at? Is the settings screen open? Are they editing the current post? In Ember.js, each of the possible states in your application is represented by a URL. Because all of the questions we asked above— Are we logged in? What post are we looking at? —are encapsulated by route handlers for the URLs, answering them is both simple and accurate. To understand why this is important, imagine we are writing a web app for managing a blog. At any given time, we should be able to answer questions like: Is the user currently logged in? Are they an admin user? What post are they looking at? Is the settings screen open? Are they editing the current post? In Ember.js, each of the possible states in your application is represented by a URL. Because all of the questions we asked above— Are we logged in? What post are we looking at? —are encapsulated by route handlers for the URLs, answering them is both simple and accurate.To understand why this is important, imagine we are writing a web app for managing a blog. At any given time, we should be able to answer questions like: Is the user currently logged in? Are they an admin user? What post are they looking at? Is the settings screen open? Are they editing the current post? In Ember.js, each of the possible states in your application is represented by a URL. Because all of the questions we asked above— Are we logged in? What post are we looking at? —are encapsulated by route handlers for the URLs, answering them is both simple and accurate.
- #10: controllers allow you to decorate your models with display logic. In general, your models will have properties that are saved to the server