machty

Check out the progress on redirectable/preventable transitions.

This consists almost entirely of a rewrite of router.js, with hardly any changes to the Ember codebase. Lots of things have been added router-wise, but this particular demo focuses on how attempted transitions can be intercepted/redirected/prevented/decorated by defining transition event handlers in a transitions hash on Ember.Route. I also added support for URL-less routes (see the URL-less States Demo at the top in the link below). You can test this out yourself with this branch of Ember, which has the new router.js code i've been working on in it.

I ended up reusing the Emblem test app, so try not to be distracted by the template syntax stuff (sorry, twas most readily available for trying this new transition code). You can check out the code for this transition demo here. Below I've highlighted the m

machty

App.Router.map ->
  @route "a"
  @route "b"
  @route "ab"
  @route "ba"

App.ARoute = Em.Route.extend
  transitions:
    'to b': (e) ->
      e.transitionTo 'ab'

machty

Argument over JSON Schemas

A colleague and I are hashing through the architecture of a website we're going to be building. One of the main requirements is that site developers/maintainers will be able to create these re-usable templates/widgets that they want to be able to re-use and display with different data on different pages.

For example, there could be a carousel widget with a title and an array of slides which each have a text blurb and image URL. This would require

machty

The Problem

We need to define a format for JSON schemas to describe the fields that a widget can have. A widget can have individual fields, or have repeatable fieldsets (in the way that a carousel widget can have a single title, as well as an array of slides with their own individual fields). My colleague and I disagree over the most intuitive format for such a schema. Please help us choose!

Option A

machty

Proposal: Generalize the Router DSL, Allow for Multiple "Routers"

Presently, you can't even use StateManager for managing the outlets of a modal view without hacking at the internals of Ember.Route, where all the rendering logic presently resides. There's a few ways we could go about exposing this, such as creating a RendererMixin, exposed to Ember.Route and Ember.State from ember-states, and some other folk are considering an Ember.Control to solve this problem.

machty

Items to Remove from Epic Machty Router.js PR

Transition event handlers

• https://github.com/tildeio/router.js/pull/11/files#L0R196
• https://github.com/tildeio/router.js/pull/11/files#L0R509
• Next two aren't crucial, but without transition event handlers, these will never evaluate to false
• https://github.com/tildeio/router.js/pull/11/files#L0R255
• https://github.com/tildeio/router.js/pull/11/files#L0R270

machty

require 'minitest/autorun'
require_relative './spec_helper'
require 'capybara_minitest_spec'
require 'serve-this'

MiniTest::Spec.class_eval do
  include Capybara::DSL
end

Capybara.app = ServeThis.from(File.join(Dir.pwd, 'spec', 'sample_template'))

machty

class StatusSnapshot < ActiveRecord::Base
  attr_accessible :error_message, :failed, :final_json, :processed_yaml, :raw_json, :tree

  #serialize :tree, StatusNode

  def version
    tree.version
  end

  class << self

machty

# Default ApplicationRoute
App.ApplicationRoute = Em.Route.extend
  events: 
    routeTo: (routeName, objects...) ->
      @router.transitionTo.apply @router, arguments

# {{linkTo}} will call routeTo

# URL changes (handleURL) will determine target route name,
# then call routeTo, so it's handleable.

machty

Proposal

1. Make transitionTo private API, only meant to be called from within a route. The only external interaction with routes or the router should be through send events.
2. Inject default routeTo handler in events hash of route:application which takes the arguments and .applys them to the route's private transitionTo.
3. Change linkTo helper to emit a routeTo event (instead of transitionTo).
4. Change handleURL to convert to a routeTo event
5. Minor change to router.js to allow for event bubbling

handleURL Complications