In config/environment.js
:
// config/environment.js
'use strict';
/*
* Mostly this is the stock module config.
import {JSONAPIURLBuilder} from "@orbit/jsonapi"; | |
import {QueryExpressionParseError} from "@orbit/data"; | |
export default class DrupalJSONAPIURLBuilder extends JSONAPIURLBuilder { | |
buildFilterParam(filterSpecifiers) { | |
const filters = []; | |
filterSpecifiers.forEach((filterSpecifier, index) => { | |
if (filterSpecifier.kind === 'passthrough') { |
This post is one in a series on converting a Backbone app to Ember. See also Ember-Data Notes.
Recently, our team has been trying to get Ember-Data to work with an API that does not conform to the json:api
standard. The experience has been mostly good, but we've really struggled with the relationships. We have a Customer
model that has many pastInvoices
and a single monthToDateInvoice
. The URL for past invoices is /billing/invoice?explicit_customer_id={{customerId}}
; for month-to-date, it's /billing?no_list=true&explicit_customer_id={{customerId}}
. The JSON that the API returns for a customer does not include any link to those URLs.
Our first attempt was to create an InvoiceAdapter
that understood how to fetch invoices from those URLs:
// app/billing/invoices/adapter.js:
Attention: the list was moved to
https://github.com/dypsilon/frontend-dev-bookmarks
This page is not maintained anymore, please update your bookmarks.
# Ruby Thread Pool | |
# ================ | |
# A thread pool is useful when you wish to do some work in a thread, but do | |
# not know how much work you will be doing in advance. Spawning one thread | |
# for each task is potentially expensive, as threads are not free. | |
# | |
# In this case, it might be more beneficial to start a predefined set of | |
# threads and then hand off work to them as it becomes available. This is | |
# the pure essence of what a thread pool is: an array of threads, all just | |
# waiting to do some work for you! |