rwjblue

• Data Down / Actions Up

  • http://emberjs.jsbin.com/nayaho/edit?html,js - Interdependent select boxes. No observers.
  • http://ember-twiddle.com/2d7246875098d0dbb4a4 - One Way Input

• Plain JSBin's

  • http://rwjblue.jsbin.com/pixeki/edit?html,js,output

• Ember Version Base JSBin's

  • 1.0 - http://emberjs.jsbin.com/juluje/edit?html,js,output

• 1.1 - http://emberjs.jsbin.com/cofufo/edit?html,js,output

palaniraja

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>items</key>
	<array>
		<dict>
			<key>assets</key>
			<array>
				<dict>

wycats

A future version of Ember will come with a new templating engine known as HTMLBars.

The original motivation for HTMLBars was to allow helpers and properties to have better contextual information about what they were bound to.

So for example, consider a template like this:

<a href="{{url}}">{{link}}</a>

ryanflorence

Dear Ember.JS team, for your consideration:

We have things like title and draggable natively: attributes that add behavior to an element. I'd like this ability in ember. It could work something like this:

App.TooltipDecorator = Ember.Decorator.extend({

 tooltipElement: function() {

lastobelus

var UrlExists = Ember.Object.extend({
  test: function(url){
    var promise = Ember.Deferred.create();
    if(Ember.isEmpty(url)){
      promise.reject(false);
    } else {
      $.getJSON("http://query.yahooapis.com/v1/public/yql?"+
        "q=select%20*%20from%20html%20where%20url%3D%22"+
        encodeURIComponent(url)+"%22&format=json'&callback=?", 
        function(data){

tpitale

In order to to add a new task for Problem 3 in the UI above, I'm hoping for a route that's something like `/problems/3/tasks/new`. This style is, of course, very much like what Rails uses.

Below is a cut down version of the router setup I'm using to to try to accomplish this URL structure. It seems strange to have a resource "problem" inside of a resource "problems", but the edit for that problem is ouside the individual problem, but inside of problems (plural).

Either way, all of this is structured in such a way as to give me the UI above, and the URL I'd like to use. To couple the UI and the URL together feels like it makes things very brittle in the router, and makes me fight against Embers' conventions.

krisselden

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',

iStefo

These are my thoughts on using the (bleeding edge) query-params-new from 1.6.0-beta.1+canary.01f3f32c.

1. Numerical Parameters

The currently handled parameter types are strings (of course), arrays (with the arr[]=foo1&arr[]=foo2 syntax, which is not the nicest but closest zu the standard) and booleans. The absence of integer parameters means having to use parseInt() in every method where the parameter is used. (Setting the parameter to a number value is no problem)

I think there are two ways to determine whether to cast or not while parsing parameters:

1. Check if param contains only digits and just assume that it's meant to be a numeric parameter then. Since this may cause unforeseen behaviour we shouldn't do this
2. Add a descriptior to the controllers queryParams to force a query parameters data type (this would also allow providing an array when the present url is arr=foo1 without the [], but I'm not sure if this is a desirable thing)