Giter Site home page Giter Site logo

guides's Introduction

Notice: This repository is deprecated

We have been working hard to make it much easier to contribute to the Ember Guides over the last 6 months. As part of this process we have re-architected the Ember Guides so they are now a fully-fledged Ember application ๐ŸŽ‰

What does this mean right now? At the time of writing we have not swapped over to the new structure but we want to keep the swap-over time to a minimum. If you want to contribute to the guides from now on you should contribute to the new infrastructure instead of this repo.

If you want to contribute to the content of the guides then make a PR on the new guides-source repo. This repo is almost 100% markdown and represents the content of the guides.

If you want to contribute to how the guides are displayed then you will probably want to contribute to the new guides-app. We will be updating the contributing guides as part of this new deployment.

Ember Guides

Build Status

This is the source for the Ember.js Guides.

Looking for repositories for other parts of the site? Check out website, ember-api-docs, super-rentals tutorial, statusboard, and styleguide

Contributing

Welcome and thanks for your help! Please see CONTRIBUTING.md for detailed instructions on how to format your work and submit a Pull Request.

Project layout

The Guides content takes the form of Markdown files (just like most READMEs). The Guides themselves are in the source folder. The left nav bar is produced from data/pages.yml. lib contains Middleman plugins, and spec contains tests for those plugins.

Running locally with Docker (recommended)

This is the recommended method for new contributors. Although the Guides are built with Ruby, most work is done in Markdown files. You don't need to know Ruby or install its dependencies to help out. Simply follow the Docker container instructions below to install and run locally.

First, install Docker and Compose and leave it running.

Next, the commands below will install all necessary dependencies for the Guides app and start a server. This will take a little while to run, possibly a few minutes. The dependencies will be installed inside a Docker container, and do not affect your normal developer environment.

git clone git://github.com/emberjs/guides.git
cd guides
docker-compose build
docker-compose up

You can view the site locally at http://localhost:4567

Running locally with Ruby and Middleman

The Docker method described above is recommended over installing dependencies separately. However, if necessary, these are the manual steps. The Guides are built with Middleman, which runs on Ruby 1.9.3 or newer.

Mac users should install Ruby using rbenv to avoid changing their OS dependencies:

brew install rbenv

Follow the rbenv installation instructions to install the Ruby version specified here, then go through the init steps, set a global version, and restart the terminal. If gem env home shows rbenv in the path, your installation was successful. You should not have to sudo install any gems.

Once you have installed Ruby, you will need bundler and Middleman:

gem install bundler middleman

During build, Middleman will require Aspell to look for misspellings. On Macs, it can be installed via Homebrew:

brew install aspell --with-lang-en

On Windows, you can download an installer, but unfortunately it is unmaintained. On Linux, you can install with your distribution's package manager. On all platforms, you can also build the most recent version from source.

Some Mac users may also need to install openSSL, which will be indicated in an error during the bundle command. See Troubleshooting.md.

To get started:

Local Dev

git clone git://github.com/emberjs/guides.git
cd guides
bundle
bundle exec middleman

Viewing

Then visit http://localhost:4567/.

If you run into problems, check Troubleshooting.md.

Spellchecking

If you have a false hit during spellchecking, you can add the word to /data/spelling-exceptions.txt. Words are line separated and case insensitive.

Maintainers

See MAINTAINERS.md.

Releasing

See https://github.com/emberjs/guides.emberjs.com.

guides's People

Contributors

acorncom avatar bmac avatar bsclifton avatar dopin avatar gavinjoyce avatar heroiceric avatar homu avatar jayjayjpg avatar josemarluedke avatar kellywerks avatar kentaro0919 avatar locks avatar mak-di avatar mamut avatar markmt avatar mattw59 avatar michaelrkn avatar mixonic avatar mozeryansky avatar poziworld avatar rimian avatar robbiethewagner avatar rtablada avatar rwjblue avatar serabe avatar thejameskylebot avatar toddjordan avatar tomdale avatar trek avatar yawboakye avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

guides's Issues

v1.11 doc is missing (updated) TodoMVC-style guide

v1.10 docs have a pretty good lead-in with a small sample application:
http://guides.emberjs.com/v1.10.0/getting-started/planning-the-application/
It covers good starting matter like:

  • Ember's opinion of what Model, View and Controller mean in a client-side world
  • Data-binding between the model and view in both directions (read and edit)
  • Binding of other actions ("delete completed")
  • Non-persistent state, and the concept that the controller is a proxy for the model which can manipulate and infer data for the view
  • Routing
  • Data persistence layers (fixtures for inital template work vs. moving to some real storage, although expanding it to continue on to a ReST endpoint would be even better)

In particular it's impressive that it starts with a spec and static mockup, because this fits the real world and keeps the whole thing in firm context of the end goal.

v1.11 docs don't seem to have these pages, but should have something covering the same ground, e.g. an updated version of the v1.10 app since for a simple example it can already cover a lot of angles.

#91 also covers Getting Started, but in the context of Ember CLI AFAICT. At least personally I already had different infrastructure around (Dancer project and some initial experiements with Backbone) so having an example which was just Ember (and Ember Data) was useful.

(Moved from emberjs/ember.js#10738 )

Update Code Blocks to include additions, removals, and highlights

A big challenge in writing tutorials where code mutates over time is accurately drawing the reader's attention to lines of code that have been added, removed, or need highlighting.

The react docs do an excellent job here:
getting started react 2015-03-22 10-52-51

They've augments the fenced code 'metadata' section with a micro syntax to define highlights:

Highlight one line:

```javascript{10}

Highlight multiple lines:

```javascript{3,10,55}

In addition to this, we can expand the syntax to include classes for line additions and removals:

Line 10 is removed:

```javascript{-10}

Line 10 is added:

```javascript{+10}

Line 10 is removed, line 15 is added, line 16 is highlighted:

```javascript{-10,+15,16}

Swiftype Middleman Plugin

We need a Swiftype middleman plugin. https://github.com/LeonB/middleman-swiftype publishes directly to Switfype, but our needs are different because publication occurs as a separate step.

A PR that addresses this issue will

  • Fork https://github.com/LeonB/middleman-swiftype and create a PR or create a new plugin (We'd prefer to update the existing plugin)
  • Provide a swiftype:generate command that outputs a search.json file
  • search.json file goes into the build directory on middleman build and middleman server
  • For every content page (e.g. not 404 page), generate an entry in search.json file

The search.json must include a documents key with an array of the following data:

  • a external_id that allows us to connect a search result back to a page
  • the following field structure
{
  "fields": [
    {"name": "title", "value": "The Page Title", "type": "string"},
    {"name": "path",  "value": "/the/page/path", "type": "string"},
    {"name": "body",  "value": "HTML content of the <p>Page</p>", "type": "string"}
  ]
}

Additionally:

  • tests must exist around all this behavior to avoid future breakage

Extract TOC and Pagination Helpers

Our table of contents and pagination generation is generally useful for anyone writing book-style content. We should extract these helpers so it will be easy to have a Gitbook like site.

A PR that successfully addresses this issue will:

  • create a new repo for making a middleman plugin
  • allow the author to provide a file in data/<name>.yml that is an array of chapter objects that contain section arrays. The data is in the following format:
- title: 'Introduction'
  url: 'index'
- title: 'Chapter 1: Call me Ishmael'
  url: 'chapter-1'
  sections:
    - title: 'A History of horror'
      url: 'index'
    - title: 'The Whale'
      url: 'the-whale'
- title: 'Chapter 2: The Imapler'
  url: 'chapter-2'
  sections:
    - title: 'Sex and Fear'
      url: 'index'

These will correspond to a file structure like this:

.
โ”œโ”€โ”€ data
โ”‚ย ย  โ””โ”€โ”€ chapters.yml
โ””โ”€โ”€ source
    โ”œโ”€โ”€ chapter-1
    โ”‚ย ย  โ”œโ”€โ”€ index.md
    โ”‚ย ย  โ””โ”€โ”€ the-whale.md
    โ”œโ”€โ”€ chapter-2
    โ”‚ย ย  โ””โ”€โ”€ index.md
    โ””โ”€โ”€ index.md
  • provide a helper to generat the table of contents on each page
  • provide a helper to link to the next section. If you're at the end of a chapter, this links to the first section in the next chapter if there is one
  • provide a helper to link to the previous section. If you're at the beginning of a chapter, this links to the last section in the previous chapter if there is one
  • provide a a helper to show the title of the next chapter/section pair
  • provide a a helper to show the title of the previous chapter/section pair
  • unit test all of this (not integation like we've had. but unit tests)

BONUS ROUND:

  • like Gitbook, allow the author to express table of contents as markdown
- title: 'Introduction'
  url: 'index'
- title: 'Chapter 1: Call me Ishmael'
  url: 'chapter-1'
  sections:
    - title: 'A History of horror'
      url: 'index'
    - title: 'The Whale'
      url: 'the-whale'
- title: 'Chapter 2: The Imapler'
  url: 'chapter-2'
  sections:
    - title: 'Sex and Fear'
      url: 'index'

becomes

* [Introduction](index.md)
* [Chapter 1: Call me Ishmael]
    * [A History of horror](chapter-1/index.md)
    * [The Whale](chapter-1/the-whale.md)
* [Chapter 2: The Imapler]
    * [Sex and Fear](chapter-2/index.md)
  • allow arbitary levels of nesting. Each section can have its own section.

version 1.11.x absent

I git cloned, and git pulled, but when I open the app in localhost, only 1.10.0 and 1.9.0 are available.

Ember CLI related sections

I'm going over the Ember CLI site right now to see what sections should be moved to emberjs.com. Not all sections are currently covered in #9 so here's a (most likely incomplete) list of topics we might need to add:

  • Managing dependencies
  • Asset compilation (using Brocfile to manage your asset pipeline)
  • Configuration / Using environments
  • Installing issues / FAQ
  • Upgrading

"Testing Components" guide is broken for Ember-CLI

The Testing Components guide doesn't work for Ember-CLI applications. Specifically, the integration test helpers aren't defined in a unit test. For example, the guide includes

moduleForComponent('my-foo', 'MyFooComponent');

test('clicking link updates the title', function() {
  var component = this.subject();

  // append the component to the DOM
  this.append();

  // assert default state
  equal(find('h2').text(), "I'm a little teapot");

  // perform click action
  click('button');

  andThen(function() { // wait for async helpers to complete
    equal(find('h2').text(), "I'm a little embereรฑo");
  });
});

but when I try to include click('button'), I get

Died on test #1     at Object.test (http://localhost:7357/assets/test-support.js:1867:13)
    at http://localhost:7357/assets/my-app.js:6443:15
    at requireModule (http://localhost:7357/assets/vendor.js:77:29)
    at Object.TestLoader.loadModules (http://localhost:7357/assets/test-loader.js:21:13)
    at Function.TestLoader.load (http://localhost:7357/assets/test-loader.js:28:24)
    at HTMLDocument.<anonymous> (http://localhost:7357/assets/test-support.js:4884:14)
    at fire (http://localhost:7357/assets/vendor.js:3261:30): click is not defined@ 23 ms
Source:     
ReferenceError: click is not defined

ensure users use node 0.12 npm 2.7 or greater

I am unsure how to wordsmith this nicely, i don't want to make a mess of the new guides but we need to ensure users start with a reasonable version of node and npm, or they will suffer the minefield of older versions.

In addition, ember-cli aims to drop support for node 0.10.x shortly, as this will allow us to rely on features like execSync without requiring some brittle c extension.

Organization of Getting Started

I keep trying to begin adding info about getting started with Ember, especially Ember CLI, and then I keep feeling like I'm going to make a mess. So I'm taking a step back, proposing an outline of what should be covered and in what order, and asking for feedback and ideas.

  • Before You Start
    • Welcome (currently source/index.md)
    • Key Background Concepts (see #85)
    • Core Ember Concepts (/source/concepts/core-concepts.md)
    • Other Terms (/source/ember-cli/glossary.md)
  • Creating An Ember App
    • Installing Ember (source/ember-cli/index.md)
    • Ember New (move over from http://www.ember-cli.com/#folder-layout and combine source/application/index.md)
    • Ember Server (needs to be written; explain asset compilation here; this would address item 2 of #31)
    • Ember Build (needs to be written; explain more asset compilation, fingerprinting here)
    • Windows (move over from http://www.ember-cli.com/#windows)

I figure we can hold off on topics like add-ons and configuration until a later section.

I also want to suggest breaking concepts/concepts/naming-conventions.md into pieces that are added to each of the relevant sections: for example, concepts/naming-conventions/#toc_simple-routes would be moved to routing/naming-conventions. An admirable goal of the guides is to "to start from the basics, and slowly increase to more sophisticated concepts", but naming conventions don't make any sense until you actually know what the thing is that you're naming.

Thoughts? Ideas? Suggestions?

For reference, the current structure looks like:

  • Getting Started
    • Installing Ember
    • Glossary
  • Getting Ember
    • Getting Ember
  • Concepts
    • Core Concepts
    • Naming Conventions
  • Application
    • Introduction

[Leaving out The Object Model which is stuck between Concepts and Application.]

Referring to objects

In an effort to find a common voice, how do we want to refer to controllers, routes, etc.?

Previously, the guides had something like ApplicationRoute. This made sense because it was defined as App.ApplicationRoute. Should we continue this or do we want to switch to controller:application?

Link to ember-cli version of TodoMVC?

I was reviewing some things the other night and couldn't find a repository with a current ember-cli version of the TodoMVC app. So I put this together: https://github.com/chrislopresto/todomvc-embercli

Each commit corresponds to a single step in the v1.10 Getting Started guide. The README lists each step along with any corresponding ember-cli generator and addon install commands.

As we shift all docs and demos to ember-cli...

  • Is this semi-useful to folks in its current state?
  • Should we link to it from the guides?
  • Would anyone like anything added or changed?

Broken link in the cookbook section (only if you follow a certain order)

Click Cookbook.

Click introduction.
http://localhost:4567/cookbook/

Scroll down and click the link that says "participating if you know Ember"
http://localhost:4567/cookbook/contributing/participating_if_you_know_ember

Scroll down that page and click the "next-guide" link,
"Participating if you don't know Ember"

Link does not work, it goes here:
http://localhost:4567/cookbook/participating_if_you_dont_know_ember/

It should go here:
http://localhost:4567/cookbook/contributing/participating_if_you_dont_know_ember

Note: Once you are on a page where the "previous" and "next" links don't work, then the sidebar links stop workiing.

Update bound attribute syntax

I believe Ember 1.11 removes the need for bind-attr, so https://github.com/emberjs/guides/blob/master/source/templates/binding-element-attributes.md and https://github.com/emberjs/guides/blob/master/source/templates/binding-element-class-names.md should be removed.

Since inline ifs are much saner to use for the new attribute binding syntax -

<div class="{{color}} {{if isEnabled 'active' 'disabled'}}"></div>

I think it would make sense to add this example to https://github.com/emberjs/guides/blob/master/source/templates/conditionals.md.

The only thing I'm not sure about is the part on Adding data attributes. Maybe this should be moved to the Views section somewhere?

Review process

Now that the guides are versioned, whats the process/timeline for getting the PR's (mostly from #9) reviewed and merged? I noticed that there's no tag for the current version 1.10.0 yet so I guess that has to happen first?

@trek I saw that the versioning process is already documented, do you have any thoughts on the review process?

Re-think glossary?

I love the idea of having a glossary containing definitions/explanations of concepts necessary to understand how to work with Ember. I imagine many developers come to Ember without knowing what concepts like promises, ES6 modules, or even Node.js really mean. I think having glossary will go a long ways towards easing Ember's learning curve. Thanks @bsclifton for putting it together!

As I've taken a closer look at the current glossary, I worry that many people will skip over it, seeing it as just a big list of terms that may or may not be helpful. While all of the currently included terms are good to know, not all of them are really necessary to get going with Ember, such as CDN and Shadow DOM.

I'd like to take a crack at re-writing a bit of it, trying to focus just on the concepts necessary to get going with Ember, and including a bit longer explanation for each of them.

If that sounds good, here is a brainstorm of what might be good to put in the glossary:

  • node.js
  • npm
  • bower
  • ES6 modules
  • promises
  • unit tests
  • acceptance tests
  • json

I'm intentionally excluding concepts that should be covered in the guides, and only including concepts that a developer should be familiar with before starting with Ember.

I'd love to get suggestions of any other concepts that the rest of the guides should be able to assume reader familiarity with.

Clarification on Rendering with Helpers

Small confusion on this page.

It first states:

{{render}} takes two parameters:

  • The first parameter describes the context to be setup
  • The optional second parameter is a model, which will be passed to the controller if provided

Then states:

  • When no model is provided it gets the singleton instance of the corresponding controller
  • When a model is provided it gets a unique instance of the corresponding controller

Then it gives an example where the code is:

<h1>{{title}}</h1>
<div>{{body}}</div>
{{render "author" author}}

In this case render gets two arguments, including a model. The description for this section states:

  • Get (or generate) the singleton instance of AuthorController

I believe this is wrong. I believe that it should be "Creates a unique instance of AuthorController". I think this is left over from when it used to only create a singleton.

[Proposal] When you change ember versions try to stay on the same section of the guide

Currently when you change the version of the ember guide it resets you to the root of the guide, which is not ideal.

I have a couple proposals for how to try and approach this with the full expectation that my understanding of how things are setup maybe totally wrong.

The simple fallback approach

When a user switches version attempt to match based on the title of the guide, if this fails match based on the section, if this fails goto root.

It may also make sense to add some sort of non title identifier to guide pages so small title changes don't cause fallback.

The manual mapping approach

In the data.yml if a guide goes away or changes in some significant way then put a manual mapping of the closest page. I would imagine that there should always be some sort of mapping possible since during the deprecation of the old feature there is normally discussion of how to upgrade / update. If there is no one to one mapping for a page then it would seem an excellent opportunity to put an upgrade guide page that explains to users the how to upgrade or simply points them to more than one guide if there is a one to many mapping.

Other side benefits

If the mapping issue is solved, especially if it's intermixed with pages helping with upgrading, a link to the new version can be placed more prominently on out of date pages encouraging users to upgrade.

Guides rewrite to use Ember CLI

Each of these needs updating to ember-cli style, include new file location feature from #35. Please comment out JSBins (since they're all broken anyway, and we need a new solution):

Offline version

How about making an offline version? Would be great. I see this unofficial one: https://leanpub.com/emberjsguides

Not sure how you build the docs but we could compile an .html file with all chapters in a single page or generate a .pdf?

Use fenced code metadata to annotate both file location and language

From the common mark spec:

The line with the opening code fence may optionally contain some text following the code fence; this is trimmed of leading and trailing spaces and called the info string. The info string may not contain any backtick characters. (The reason for this restriction is that otherwise some inline code would be incorrectly interpreted as the beginning of a fenced code block.)

Where we annotate the code's language

```javascript
var someCode;

We can annotate filename and extension:

```app/templates/foo.hbs
{{rock-on}}

We have a custom highlighter that outputs particular markup/styles for specific languages.

A PR that addresses this Issue will:

  • continue to detect bare named language fences
  • begin to detect language name from file path fences
  • output nice markup/style that decorates an HTML code block something that shows file location

@danmcclain has a sample markup/design

Reaudit Routing Guides

There are many find/replace errors:

  • check every file
  • use type-style folders
  • republish v1.11.0 to divshot

Version dropdown is empty if JS is disabled

In theory most of the guides functionality should work without JS, however, the version selector just shows up blank. If JS isn't available, we should at least not display it.

missing/weird links in guides v1.11.0

First, it would be helpful if the installing ember page in the guides had a link to http://www.ember-cli.com

That's a very important site with documentation that isn't available elsewhere. I'd mention it right up top when talking about installing ember-cli, but you could put it a little further on. Figuring out ember-cli from the --help text alone is pretty cryptic.

Second, in the same section, there is a link tied to NPM but it points back to the same paragraph that contains the link. A little strange and confusing. You can click it all day long and nothing seems to happen :-) Unless you are trying to play tricks on people, you might want to either actually link to a page about nom or remove the link.

can you tell me when to use this code ?

    import TodosController from 'app/controllers/todos';
   todosController = TodosController.create();
   todosController.get('remaining');

hmm,i dont know in what situation ,i need to import another controller

Annotating code samples with file names

Do we have a policy on annotating our code samples with file names?

In #11, it looks like we're using the traditional structure (e.g. // app/controllers/comments.js). But, in #8, we're using the pod structure (e.g. // app/post/route.js).

We should probably standardize on one.

I'm also wondering if we should include them at all for code samples where the file name doesn't really matter. For example, in the section on routes, we a route like this:

App.GoodForNothingRoute = Ember.Route.extend({โ€ฆ});

Should we bother making up a file name in this case? (I don't really care as long as we all decide to do the same thing.)

/cc @joostdevries and @locks

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.