Skip to content

Instantly share code, notes, and snippets.


Alex Matchneer machty

View GitHub Profile
View manifest.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">

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>

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 / gist:7943705
Last active Dec 31, 2015
An asynchronous, debounced, optionally caching validator for ember-validations (requires my patch in pull request 64)
View gist:7943705
var UrlExists = Ember.Object.extend({
test: function(url){
var promise = Ember.Deferred.create();
} else {
tpitale / Notes.txt
Created Dec 9, 2013
Notes on "complex" nested routes/urls/views in Ember
View Notes.txt
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.
View fast-select.js
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 / gist:9267640
Created Feb 28, 2014
my thoughts on query-params-new
View gist:9267640

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)
You can’t perform that action at this time.