trabus

define(
    ['ember', 'app'],
    function(Em, App){
        /*
        Mobile template resolver (borrowed from Discourse)
        If the app is in mobile mode, it will look for a mobile template instead
        */
        App.Resolver = Em.DefaultResolver.extend({
            resolveTemplate: function(parsedName){
                var t = this._super();

trabus

/*
Simply modify the output after calling app.toTree(). The final destination is completely up to you.
Something like the following in your Brocfile:
*/
var pickFiles = require('broccoli-static-compiler');

// default app = new EmberApp stuff here

var appTree = app.toTree();

trabus

var get = Ember.get, set = Ember.set, doc = document;

var FastSelectComponent = Ember.Component.extend({
  items: null,
  valuePath: 'value',
  labelPath: 'label',
  value: null,
  selected: null,

  tagName: 'select',

trabus

Folder Structure

Motivations

• Clear feature ownership
• Module usage predictibility (refactoring, maintainence, you know what's shared, what's not, prevents accidental regressions, avoids huge directories of not-actually-reusable modules, etc)

trabus

Resolver Idea for Structures

Resolver rules don't belong in structures

Structures don't need to have the lookup pattern defined in them, they should instead conform to available patterns provided by the resolver. The issue is that the resolver deals with compiled modules, and structures are for pre-compilation. The resolver does have a role in how structures should work, but it shouldn't be coupled to the way the structure is defined. The difficulty of getting the resolver rules out of the structure and into the resolver also shows that it's not the right path.

The resolver could use a hash to resolve different types, defining the prefix to use for each, as well as the structures supported (implied by the prefix). For this example let's assume there is no 'pods' folder, but rather the prefix describes the structure used in the folder. We should also assume that modules of a specific type are only generated in pod or type structure, not both. This config example is a bit contrived, and doesn't take in

trabus

module.exports = {
  description: '',
  // overwriting install, acting as a proxy to the component-test blueprint
  install: function(options){
      this.project = options.project;
      this.ui = options.ui;
      var testBlueprint = this.lookupBlueprint('component-test');
      return testBlueprint.install(options);
  }
};

trabus

import Ember from 'ember';

export default Ember.Controller.extend({
  appName:'Ember Twiddle',
  initData: Ember.on('init',function(){
    // this would normally happen with the route model hook
    // when the data response comes back, this happens automatically behind the scenes
    this.store.pushPayload({yearbooks:[
    {id: 1, name: 'yearbook 1'},
    {id: 2, name: 'yearbook 2'},

trabus

In 1.13.0-beta.1 and above, the childViews array is not maintained (HTMLBars maintains a tree structure instead of a flat array listing).

I spiked getting things working for both pre-1.13 and post in this JSBin, snippet below:

  didRender: function() { 
    function filterAttrMorphs(node) {
      return node.constructor.name !== 'AttrMorph';
    }
    var childViews = this._renderNode.childNodes.filter(filterAttrMorphs)[0].childNodes
 .map(function(node) {

trabus

copy: {
  main: {
    files: [
      {src: ['foo/**', '!**/_*/**'], dest:'temp/'}
    ]
  }
}

trabus

// ----------------------------------------------------------
// A short snippet for detecting versions of IE in JavaScript
// without resorting to user-agent sniffing
// ----------------------------------------------------------
// If you're not in IE (or IE version is less than 5) then:
//     ie === undefined
// If you're in IE (>=5) then you can determine which version:
//     ie === 7; // IE7
// Thus, to detect IE:
//     if (ie) {}