spade 0.0.1 → 0.0.2

data/sproutcore/frameworks/core_tools/models/target.js

@@ -1,108 +0,0 @@
-// ==========================================================================
-// Project:   CoreTools.Target
-// Copyright: ©2010 Apple Inc.
-// ==========================================================================
-/*globals CoreTools */
-
-/** @class
-
-  Describes a target in the build system.
-
-  @extends SC.Record
-*/
-CoreTools.Target = SC.Record.extend(
-/** @scope CoreTools.Target.prototype */ {
-
-  primaryKey: "name",
-  
-  /**
-    Name of target.  This is also the primary key.
-  */
-  name: SC.Record.attr(String),
-  
-  /**
-    Parent of target.  Only non-null for nested targets.
-  */
-  parent: SC.Record.toOne("CoreTools.Target"),
-
-  /**
-    URL to use to load tests.
-  */
-  testsUrl: SC.Record.attr(String, { key: "link_tests" }),
-  
-  /**  
-    URL to use to load the app.  If no an app, returns null
-  */
-  appUrl: function() {
-    return (this.get('kind') === 'app') ? this.get('name') : null;
-  }.property('kind', 'name').cacheable(),
-  
-  /**
-    The isExpanded state.  Defaults to NO on load.
-  */
-  isExpanded: SC.Record.attr(Boolean, { defaultValue: NO }),
-  
-  /**
-    Children of this target.  Computed by getting the loaded targets
-  */
-  children: function() {
-    var store = this.get('store'),
-        query = CoreTools.TARGETS_QUERY,
-        ret   = store.find(query).filterProperty('parent', this);
-        
-    if (ret) ret = ret.sortProperty('kind', 'displayName');
-    return (ret && ret.get('length')>0) ? ret : null ;
-  }.property().cacheable(),
-  
-  /**
-    Display name for this target
-  */
-  displayName: function() {
-    var name = (this.get('name') || '(unknown)').split('/');
-    return name[name.length-1];
-  }.property('name').cacheable(),
-  
-  /**
-    The icon to display.  Based on the type.
-  */
-  targetIcon: function() {
-    var ret = 'sc-icon-document-16';
-    switch(this.get('kind')) {
-      case "framework":
-        ret = 'sc-icon-folder-16';
-        break;
-        
-      case "app":
-        ret = 'sc-icon-options-16';
-        break;
-    }
-    return ret ;
-  }.property('kind').cacheable(),
-  
-  /**
-    This is the group key used to display.  Will be the kind unless the item
-    belongs to the sproutcore target.
-  */
-  sortKind: function() {
-    if (this.get('name') === '/sproutcore') return null;
-    var parent = this.get('parent');
-    if (parent && (parent.get('name') === '/sproutcore')) return 'sproutcore';
-    else return (this.get('kind') || 'unknown').toLowerCase();
-  }.property('kind', 'parent').cacheable(),
-  
-  
-  testsQuery: function() {
-    return SC.Query.remote(CoreTools.Test, { url: this.get('testsUrl') });
-  }.property('testsUrl').cacheable(),
-  
-  /**
-    Returns all of the tests associated with this target by fetching the
-    testsUrl.
-  */
-  tests: function() {
-    return this.get('store').find(this.get('testsQuery'));
-  }.property('testsQuery').cacheable()
-  
-}) ;
-
-CoreTools.TARGETS_QUERY = SC.Query.remote(CoreTools.Target);

data/sproutcore/frameworks/core_tools/models/test.js

@@ -1,48 +0,0 @@
-// ==========================================================================
-// Project:   CoreTools.Test
-// Copyright: ©2010 Apple Inc.
-// ==========================================================================
-/*globals CoreTools */
-
-/** @class
-
-  (Document your Model here)
-
-  @extends SC.Record
-  @version 0.1
-*/
-CoreTools.Test = SC.Record.extend(
-/** @scope CoreTools.Test.prototype */ {
-
-  primaryKey: "url",
-  
-  /**
-    The filename for this test.
-  */
-  filename: SC.Record.attr(String),
-  
-  /**
-    The test URL.
-  */
-  url: SC.Record.attr(String),
-
-  /**
-    Display name to show in the tests UI.  This is computed by removing some
-    generic cruft from the filename.
-  */
-  displayName: function() {
-    return (this.get('filename') || '').replace(/^tests\//,'');
-  }.property('filename').cacheable(),
-
-  /**
-    Test icon.  To be replaced eventually with actual pass|fail icons
-  */
-  icon: 'sc-icon-document-16',
-
-  /**
-    Shows the "branch" at the right of the list.  Eventually this will be
-    computed based on whether the test is a summary of other tests or not.
-  */
-  isRunnable: YES
-  
-}) ;

data/sproutcore/frameworks/datastore/core.js

@@ -1,8 +0,0 @@
-// ==========================================================================
-// Project:   SproutCore - JavaScript Application Framework
-// Copyright: ©2006-2011 Strobe Inc. and contributors.
-//            Portions ©2008-2010 Apple Inc. All rights reserved.
-// License:   Licensed under MIT license (see license.js)
-// ==========================================================================
-
-// Place any global constants here

data/sproutcore/frameworks/datastore/data_sources/cascade.js

@@ -1,180 +0,0 @@
-// ==========================================================================
-// Project:   SproutCore - JavaScript Application Framework
-// Copyright: ©2006-2011 Strobe Inc. and contributors.
-//            Portions ©2008-2010 Apple Inc. All rights reserved.
-// License:   Licensed under MIT license (see license.js)
-// ==========================================================================
-
-sc_require('data_sources/data_source');
-
-/** @class
-
-  A cascading data source will actually forward requests onto an array of 
-  additional data sources, stopping when one of the data sources returns YES,
-  indicating that it handled the request.  
-  
-  You can use a cascading data source to tie together multiple data sources,
-  treating them as a single namespace.
-  
-  h2. Configuring a Cascade Data Source
-  
-  You will usually define your cascading data source in your main method after
-  all the classes you have are loaded.
-  
-  {{{
-    MyApp.dataSource = SC.CascadeDataSource.create({
-      dataSources: "prefs youtube photos".w(),
-      
-      prefs:   MyApp.PrefsDataSource.create({ root: "/prefs" }),
-      youtube: YouTube.YouTubeDataSource.create({ apiKey: "123456" }),
-      photos:  MyApp.PhotosDataSource.create({ root: "photos" })
-      
-    });
-    
-    MyApp.store.set('dataSource', MyApp.dataSource);
-  }}}
-  
-  Note that the order you define your dataSources property will determine the
-  order in which requests will cascade from the store.
-  
-  Alternatively, you can use a more jQuery-like API for defining your data
-  sources:
-  
-  {{{
-    MyApp.dataSource = SC.CascadeDataSource.create()
-      .from(MyApp.PrefsDataSource.create({ root: "/prefs" }))
-      .from(YouTube.YouTubeDataSource.create({ apiKey: "123456" }))
-      .from(MyApp.PhotosDataSource.create({ root: "photos" }));
-
-    MyApp.store.set('dataSource', MyApp.dataSource);
-  }}}
-
-  In this case, the order you call from() will determine the order the request
-  will cascade.
-  
-  @extends SC.DataSource
-  @since SproutCore 1.0
-*/
-SC.CascadeDataSource = SC.DataSource.extend( 
-  /** @scope SC.CascadeDataSource.prototype */ {
-
-  /**
-    The data sources used by the cascade, in the order that they are to be 
-    followed.  Usually when you define the cascade, you will define this
-    array.
-    
-    @property {Array}
-  */
-  dataSources: null,
-
-  /**
-    Add a data source to the list of sources to use when cascading.  Used to
-    build the data source cascade effect.
-
-    @param {SC.DataSource} dataSource a data source instance to add.
-    @returns {SC.CascadeDataSource} receiver
-  */
-  from: function(dataSource) {
-    var dataSources = this.get('dataSources');
-    if (!dataSources) this.set('dataSources', dataSources = []);
-    dataSources.push(dataSource);
-    return this ;
-  },
-    
-  // ..........................................................
-  // SC.STORE ENTRY POINTS
-  // 
-  
-  /** @private - just cascades */
-  fetch: function(store, query) {
-    var sources = this.get('dataSources'), 
-        len     = sources ? sources.length : 0,
-        ret     = NO,
-        cur, source, idx;
-    
-    for(idx=0; (ret !== YES) && idx<len; idx++) {
-      source = sources.objectAt(idx);
-      cur = source.fetch ? source.fetch.apply(source, arguments) : NO;
-      ret = this._handleResponse(ret, cur);
-    }
-    
-    return ret ;
-  },
-  
-  
-  /** @private - just cascades */
-  retrieveRecords: function(store, storeKeys, ids) {
-    var sources = this.get('dataSources'), 
-        len     = sources ? sources.length : 0,
-        ret     = NO,
-        cur, source, idx;
-    
-    for(idx=0; (ret !== YES) && idx<len; idx++) {
-      source = sources.objectAt(idx);
-      cur = source.retrieveRecords.apply(source, arguments);
-      ret = this._handleResponse(ret, cur);
-    }
-    
-    return ret ;
-  },
-
-  /** @private - just cascades */
-  commitRecords: function(store, createStoreKeys, updateStoreKeys, destroyStoreKeys) {
-    var sources = this.get('dataSources'), 
-        len     = sources ? sources.length : 0,
-        ret     = NO,
-        cur, source, idx;
-    
-    for(idx=0; (ret !== YES) && idx<len; idx++) {
-      source = sources.objectAt(idx);
-      cur = source.commitRecords.apply(source, arguments);
-      ret = this._handleResponse(ret, cur);
-    }
-    
-    return ret ;
-  },
-
-  /** @private - just cascades */
-  cancel: function(store, storeKeys) {
-    var sources = this.get('dataSources'), 
-        len     = sources ? sources.length : 0,
-        ret     = NO,
-        cur, source, idx;
-    
-    for(idx=0; (ret !== YES) && idx<len; idx++) {
-      source = sources.objectAt(idx);
-      cur = source.cancel.apply(source, arguments);
-      ret = this._handleResponse(ret, cur);
-    }
-    
-    return ret ;
-  },
-  
-  // ..........................................................
-  // INTERNAL SUPPORT
-  // 
-  
-  /** @private */
-  init: function() {
-    sc_super();
-    
-    // if a dataSources array is defined, look for any strings and lookup 
-    // the same on the data source.  Replace.
-    var sources = this.get('dataSources'),
-        idx     = sources ? sources.get('length') : 0,
-        source;
-    while(--idx>=0) {
-      source = sources[idx];
-      if (SC.typeOf(source) === SC.T_STRING) sources[idx] = this.get(source);
-    }
-    
-  },
-
-  /** @private - Determine the proper return value. */
-  _handleResponse: function(current, response) {
-    if (response === YES) return YES ;
-    else if (current === NO) return (response === NO) ? NO : SC.MIXED_STATE ;
-    else return SC.MIXED_STATE ;
-  }
-    
-});

data/sproutcore/frameworks/datastore/data_sources/data_source.js

@@ -1,583 +0,0 @@
-// ==========================================================================
-// Project:   SproutCore - JavaScript Application Framework
-// Copyright: ©2006-2011 Strobe Inc. and contributors.
-//            Portions ©2008-2010 Apple Inc. All rights reserved.
-// License:   Licensed under MIT license (see license.js)
-// ==========================================================================
-
-
-/** @class
-
-  A DataSource connects an in-memory store to one or more server backends. 
-  To connect to a data backend on a server, subclass `SC.DataSource`
-  and implement the necessary data source methods to communicate with the 
-  particular backend. 
-  
-  
-  h2. Create a Data Source
-  
-  To implement the data source, subclass `SC.DataSource` in a file located 
-  either in the root level of your app or framework, or in a directory
-  called "data_sources":
-  
-	{{{
-  	MyApp.DataSource = SC.DataSource.extend({
-  		// implement the data source API...
-  	});
-	}}}
-  
-  
-	h2. Connect to a Data Source
-	
-	New SproutCore applications are wired up to fixtures as their data source.
-  When you are ready to connect to a server, swap the use of fixtures with a 
-  call to the desired data source. 
-  
-  In core.js:
-  
-  {{{
-  	// change...
-  	store: SC.Store.create().from(SC.Record.fixtures)
-  	
-  	// to...
-  	store: SC.Store.create().from('MyApp.DataSource')
-  }}}
-  
-  Note that the data source class name is referenced by string since the file
-  in which it is defined may not have been loaded yet. The first time a 
-  data store tries to access its data source it will look up the class name 
-  and instantiate that data source. 
-  
-  
-  h2. Implement the Data Source API
-  
-	There are three methods that a data store invokes on its data source:
-  
-  <ul>
-  	<li>
-  		`fetch()` &mdash; called the first time you try to `find()` a query 
-  		on a store or any time you refresh the record array after that.
-	  </li>
-  	<li>
-  		`retrieveRecords()` &mdash; called when you access an individual 
-  		record that has not been loaded yet
-		</li>
-		<li>
-			`commitRecords()` &mdash; called if the the store has changes 
-			pending and its `commitRecords()` method is invoked.
-		</li>
-	</ul>
-
-	The data store will call the `commitRecords()` method when records 
-	need to be created, updated, or deleted. If the server that the data source
-	connects to handles these three actions in a uniform manner, it may be 
-	convenient to implement the `commitRecords()` to handle record 
-	creation, updating, and deletion. 
-	
-	However, if the calls the data source will need to make to the server to 
-	create, update, and delete records differ from each other to a significant 
-	enough degree, it will be more convenient to rely on the default behavior
-	of `commitRecords()` and instead implement the three methods that
-	it will call by default:
-	
-	<ul>
-		<li>
-			`createRecords()` &mdash; called with a list of records that are new 
-			and need to be created on the server.
-		</li>
-		<li>
-			`updateRecords()` &mdash; called with a list of records that already 
-			exist on the server but that need to be updated.
-		</li>
-		<li>
-			`destroyRecords()` &mdash; called with a list of records that should 
-			be deleted on the server.
-		</li>
-	</ul>
-			
-	
-	h3. Multiple records
-	
-	The `retrieveRecords()`, `createRecords()`, `updateRecords()` and 
-	`destroyRecords()` 	methods all work on multiple records. If your server 
-	API accommodates calls	where you can	pass a list of records, this might 
-	be the best level at which to implement the Data Source API. On the other 
-	hand, if the server requires that you send commands for it for individual 
-	records, you can rely on the default implementation of these four methods, 
-	which will call the following for each individual record, one at a time:
-	
-	- `retrieveRecord()` &mdash; called to retrieve a single record.
-	- `createRecord()` &mdash; called to create a single record.
-	- `updateRecord()` &mdash; called to update a single record.
-	- `destroyRecord()` &mdash; called to destroy a single record.
-	
-	
-	h3. Return Values
-	
-	All of the methods you implement must return one of three values:
-	- `YES` &mdash; all the records were handled.
-	- `NO` &mdash; none of the records were handled.
-	- `SC.MIXED_STATE` &mdash; some, but not all of the records were handled.
-	
-	
-	h3. Store Keys  
-	
-	Whenever a data store invokes one of the data source methods it does so 
-	with a storeKeys or storeKey argument. Store keys are transient integers
-	assigned to each data hash when it is first loaded into the store. It is
-	used to track data hashes as they move up and down nested stores (even if
-	no associated record is ever created from it).
-	
-	When passed a storeKey you can use it to retrieve the status, data hash,
-	record type, or record ID, using the following data store methods:
-	
-	<ul>
-		<li>
-			`readDataHash(storeKey)` &mdash; returns the data hash associated with 
-			a store key, if any.
-		</li>
-		<li>
-			`readStatus(storeKey)` &mdash; returns the current record status 
-			associated with the store key. May be `SC.Record.EMPTY`.
-		</li>
-		<li>
-			`SC.Store.recordTypeFor(storeKey)` &mdash; returns the record type for 
-			the associated store key.
-		</li>
-		<li>
-			`recordType.idFor(storeKey)` &mdash; returns the record ID for
-			the associated store key. You must call this method on `SC.Record`
-			subclass itself, not on an instance of `SC.Record`.
-		</li>
-	</ul>
-	
-	These methods are safe for reading data from the store. To modify data 
-	in the data store you must use the store callbacks described below. The
-	store callbacks will ensure that the record states remain consistent. 
-	
-	
-	h3. Store Callbacks
-	
-	When a data store calls a data source method, it puts affected records into 
-	a `BUSY` state. To guarantee data integrity and consistency, these records 
-	cannot be modified by the rest of the application while they are in the `BUSY` 
-	state. 
-	
-	Because records are "locked" while in the `BUSY` state, it is the data source's	
-	responsibility to invoke a callback on the store for each record or query that 
-	was passed to it and that the data source handled. To reduce the amount of work 
-	that a data source must do, the data store will automatically unlock the relevant 
-	records if the the data source method returned `NO`, indicating that the records 
-	were unhandled. 
-	
-	Although a data source can invoke callback methods at any time, they should 
-	usually be invoked after receiving a response from the server. For example, when 
-	the data source commits a change to a record by issuing a command to the server, 
-	it waits for the server to acknowledge the command before invoking the 
-	`dataSourceDidComplete()` callback. 
-	
-	In some cases a data source may be able to assume a server's response and invoke 
-	the callback on the store immediately. This can improve performance because the 
-	record can be unlocked right away.
-	
-	
-	h3. Record-Related Callbacks
-	
-	When `retrieveRecords()`, `commitRecords()`, or any of the related methods are
-	called on a data source, the store puts any records to be handled by the data 
-	store in a `BUSY` state. To release the records the data source must invoke one 
-	of the record-related callbacks on the store:
-	
-	<ul>
-		<li>
-			`dataSourceDidComplete(storeKey, dataHash, id)` &mdash; the most common 
-			callback. You might use this callback when you have retrieved a record to	
-			load its contents into the store. The callback tells the store that the data 
-			source is finished with the storeKey in question. The `dataHash` and `id`	
-			arguments are optional and will replace the current dataHash and/or id. Also 
-			see "Loading Records" below.
-		</li>
-		<li>
-			`dataSourceDidError(storeKey, error)` &mdash; a data source should call this 
-			when a request could not be completed because an error occurred. The error
-			argument is optional and can contain more information about the error.
-		</li>
-		<li>
-			`dataSourceDidCancel(storeKey)` &mdash; a data source should call this when 
-			an operation is cancelled for some reason. This could be used when the user 
-			is able to cancel an operation that is in progress. 
-		</li>
-	</ul>
-	
-	h3. Loading Records into the Store
-	
-	Instead of orchestrating multiple `dataSourceDidComplete()` callbacks when loading 
-	multiple records, a data source can call the `loadRecords()` method on the store, 
-	passing in a `recordType`, and array of data hashes, and optionally an array of ids. 
-	The `loadRecords()` method takes care of looking up storeKeys and calling the 
-	`dataSourceDidComplete()` callback as needed. 
-	
-	`loadRecords()` is often the most convenient way to get large blocks of data into 
-	the store, especially in response to a `fetch()` or `retrieveRecords()` call.
-	
-	
-	h3. Query-Related Callbacks
-	
-	Like records, queries that are passed through the `fetch()` method also have an 
-	associated status property; accessed through the `status`	property on the record 
-	array returned from `find()`. To properly reset this status, a data source must 
-	invoke an appropriate query-related callback on the store. The callbacks for 
-	queries are similar to those for records:
-	
-	<ul>
-		<li>
-			`dataSourceDidFetchQuery(query)` &mdash; the data source must call this when 
-			it has completed fetching any related data for the query. This returns the 
-			query results (record array) status into a `READY` state. 
-		</li>
-		<li>
-			`dataSourceDidErrorQuery(query, error)` &mdash; the data source should call 
-			this if it encounters an error in executing the query. This puts the query 
-			results into an `ERROR` state. 
-		</li>
-		<li>
-			`dataSourceDidCancelQuery(query)` &mdash; the data source should call this 
-			if loading the results is cancelled.
-		</li>
-	</ul>
-	
-	In addition to these callbacks, the method `loadQueryResults(query, storeKey)` 
-	is used by data sources when handling remote queries. This method is similar to 
-	`dataSourceDidFetchQuery()`, except that you also provide an array of storeKeys 
-	(or a promise to provide store keys) that comprises the result set.
-	
-	
-  
-  @extend SC.Object
-  @since SproutCore 1.0
-*/
-SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
-
-  // ..........................................................
-  // SC.STORE ENTRY POINTS
-  // 
-  
-
-  /**
-  
-    Invoked by the store whenever it needs to retrieve data matching a 
-    specific query, triggered by find().  This method is called anytime
-    you invoke SC.Store#find() with a query or SC.RecordArray#refresh().  You 
-    should override this method to actually retrieve data from the server 
-    needed to fulfill the query.  If the query is a remote query, then you 
-    will also need to provide the contents of the query as well.
-    
-    h3. Handling Local Queries
-    
-    Most queries you create in your application will be local queries.  Local
-    queries are populated automatically from whatever data you have in memory.
-    When your fetch() method is called on a local queries, all you need to do
-    is load any records that might be matched by the query into memory. 
-    
-    The way you choose which queries to fetch is up to you, though usually it
-    can be something fairly straightforward such as loading all records of a
-    specified type.
-    
-    When you finish loading any data that might be required for your query, 
-    you should always call SC.Store#dataSourceDidFetchQuery() to put the query 
-    back into the READY state.  You should call this method even if you choose
-    not to load any new data into the store in order to notify that the store
-    that you think it is ready to return results for the query.
-    
-    h3. Handling Remote Queries
-    
-    Remote queries are special queries whose results will be populated by the
-    server instead of from memory.  Usually you will only need to use this 
-    type of query when loading large amounts of data from the server.
-    
-    Like Local queries, to fetch a remote query you will need to load any data
-    you need to fetch from the server and add the records to the store.  Once
-    you are finished loading this data, however, you must also call
-    SC.Store#loadQueryResults() to actually set an array of storeKeys that
-    represent the latest results from the server.  This will implicitly also
-    call datasSourceDidFetchQuery() so you don't need to call this method 
-    yourself.
-    
-    If you want to support incremental loading from the server for remote 
-    queries, you can do so by passing a SC.SparseArray instance instead of 
-    a regular array of storeKeys and then populate the sparse array on demand.
-    
-    h3. Handling Errors and Cancelations
-    
-    If you encounter an error while trying to fetch the results for a query 
-    you can call SC.Store#dataSourceDidErrorQuery() instead.  This will put
-    the query results into an error state.  
-    
-    If you had to cancel fetching a query before the results were returned, 
-    you can instead call SC.Store#dataSourceDidCancelQuery().  This will set 
-    the query back into the state it was in previously before it started 
-    loading the query.
-    
-    h3. Return Values
-    
-    When you return from this method, be sure to return a Boolean.  YES means
-    you handled the query, NO means you can't handle the query.  When using
-    a cascading data source, returning NO will mean the next data source will
-    be asked to fetch the same results as well.
-    
-    @param {SC.Store} store the requesting store
-    @param {SC.Query} query query describing the request
-    @returns {Boolean} YES if you can handle fetching the query, NO otherwise
-  */
-  fetch: function(store, query) {
-    return NO ; // do not handle anything!
-  },
-  
-  /**
-    Called by the store whenever it needs to load a specific set of store 
-    keys.  The default implementation will call retrieveRecord() for each
-    storeKey.  
-    
-    You should implement either retrieveRecord() or retrieveRecords() to 
-    actually fetch the records referenced by the storeKeys .
-    
-    @param {SC.Store} store the requesting store
-    @param {Array} storeKeys
-    @param {Array} ids - optional
-    @returns {Boolean} YES if handled, NO otherwise
-  */
-  retrieveRecords: function(store, storeKeys, ids) {
-    return this._handleEach(store, storeKeys, this.retrieveRecord, ids);  
-  },
-  
-  /**
-    Invoked by the store whenever it has one or more records with pending 
-    changes that need to be sent back to the server.  The store keys will be
-    separated into three categories:
-    
-     - createStoreKeys: records that need to be created on server
-     - updateStoreKeys: existing records that have been modified
-     - destroyStoreKeys: records need to be destroyed on the server
-     
-    If you do not override this method yourself, this method will actually
-    invoke createRecords(), updateRecords(), and destroyRecords() on the 
-    dataSource, passing each array of storeKeys.  You can usually implement
-    those methods instead of overriding this method.
-    
-    However, if your server API can sync multiple changes at once, you may
-    prefer to override this method instead.
-    
-    To support cascading data stores, be sure to return NO if you cannot 
-    handle any of the keys, YES if you can handle all of the keys, or
-    SC.MIXED_STATE if you can handle some of them.
-
-    @param {SC.Store} store the requesting store
-    @param {Array} createStoreKeys keys to create
-    @param {Array} updateStoreKeys keys to update
-    @param {Array} destroyStoreKeys keys to destroy
-    @param {Hash} params to be passed down to data source. originated
-      from the commitRecords() call on the store
-    @returns {Boolean} YES if data source can handle keys
-  */
-  commitRecords: function(store, createStoreKeys, updateStoreKeys, destroyStoreKeys, params) {
-    var cret, uret, dret;
-    if (createStoreKeys.length>0) {
-      cret = this.createRecords.call(this, store, createStoreKeys, params);
-    }
-        
-    if (updateStoreKeys.length>0) {
-      uret = this.updateRecords.call(this, store, updateStoreKeys, params); 
-    }
-       
-    if (destroyStoreKeys.length>0) {
-      dret = this.destroyRecords.call(this, store, destroyStoreKeys, params);
-    }
-     
-    return ((cret === uret) && (cret === dret)) ? cret : SC.MIXED_STATE;
-  },
-  
-  /**
-    Invoked by the store whenever it needs to cancel one or more records that
-    are currently in-flight.  If any of the storeKeys match records you are
-    currently acting upon, you should cancel the in-progress operation and 
-    return YES.
-    
-    If you implement an in-memory data source that immediately services the
-    other requests, then this method will never be called on your data source.
-    
-    To support cascading data stores, be sure to return NO if you cannot 
-    retrieve any of the keys, YES if you can retrieve all of the, or
-    SC.MIXED_STATE if you can retrieve some of the.
-    
-    @param {SC.Store} store the requesting store
-    @param {Array} storeKeys array of storeKeys to retrieve
-    @returns {Boolean} YES if data source can handle keys
-  */
-  cancel: function(store, storeKeys) {
-    return NO;
-  },
-  
-  // ..........................................................
-  // BULK RECORD ACTIONS
-  // 
-  
-  /**
-    Called from commitRecords() to commit modified existing records to the 
-    store.  You can override this method to actually send the updated 
-    records to your store.  The default version will simply call 
-    updateRecord() for each storeKey.
-
-    To support cascading data stores, be sure to return NO if you cannot 
-    handle any of the keys, YES if you can handle all of the keys, or
-    SC.MIXED_STATE if you can handle some of them.
-
-    @param {SC.Store} store the requesting store
-    @param {Array} storeKeys keys to update
-    @param {Hash} params 
-      to be passed down to data source. originated from the commitRecords() 
-      call on the store
-
-    @returns {Boolean} YES, NO, or SC.MIXED_STATE  
-
-  */
-  updateRecords: function(store, storeKeys, params) {
-    return this._handleEach(store, storeKeys, this.updateRecord, null, params);
-  },
-  
-  /**
-    Called from commitRecords() to commit newly created records to the 
-    store.  You can override this method to actually send the created 
-    records to your store.  The default version will simply call 
-    createRecord() for each storeKey.
-
-    To support cascading data stores, be sure to return NO if you cannot 
-    handle any of the keys, YES if you can handle all of the keys, or
-    SC.MIXED_STATE if you can handle some of them.
-
-    @param {SC.Store} store the requesting store
-    @param {Array} storeKeys keys to update
-    
-    @param {Hash} params 
-      to be passed down to data source. originated from the commitRecords() 
-      call on the store
-    
-    @returns {Boolean} YES, NO, or SC.MIXED_STATE  
-  
-  */
-  createRecords: function(store, storeKeys, params) {
-    return this._handleEach(store, storeKeys, this.createRecord, null, params);
-  },
-
-  /**
-    Called from commitRecords() to commit destroted records to the 
-    store.  You can override this method to actually send the destroyed 
-    records to your store.  The default version will simply call 
-    destroyRecord() for each storeKey.
-
-    To support cascading data stores, be sure to return NO if you cannot 
-    handle any of the keys, YES if you can handle all of the keys, or
-    SC.MIXED_STATE if you can handle some of them.
-
-    @param {SC.Store} store the requesting store
-    @param {Array} storeKeys keys to update
-    @param {Hash} params to be passed down to data source. originated
-      from the commitRecords() call on the store
-
-    @returns {Boolean} YES, NO, or SC.MIXED_STATE  
-
-  */
-  destroyRecords: function(store, storeKeys, params) {
-    return this._handleEach(store, storeKeys, this.destroyRecord, null, params);
-  },
-
-  /** @private
-    invokes the named action for each store key.  returns proper value
-  */
-  _handleEach: function(store, storeKeys, action, ids, params) {
-    var len = storeKeys.length, idx, ret, cur, lastArg;
-    if(!ids) ids = [];
-    
-    for(idx=0;idx<len;idx++) {
-      lastArg = ids[idx] ? ids[idx] : params;
-      
-      cur = action.call(this, store, storeKeys[idx], lastArg, params);
-      if (ret === undefined) {
-        ret = cur ;
-      } else if (ret === YES) {
-        ret = (cur === YES) ? YES : SC.MIXED_STATE ;
-      } else if (ret === NO) {
-        ret = (cur === NO) ? NO : SC.MIXED_STATE ;
-      }
-    }
-    return ret ? ret : null ;
-  },
-  
-
-  // ..........................................................
-  // SINGLE RECORD ACTIONS
-  // 
-  
-  /**
-    Called from updatesRecords() to update a single record.  This is the 
-    most basic primitive to can implement to support updating a record.
-    
-    To support cascading data stores, be sure to return NO if you cannot 
-    handle the passed storeKey or YES if you can.
-    
-    @param {SC.Store} store the requesting store
-    @param {Array} storeKey key to update
-    @param {Hash} params to be passed down to data source. originated
-      from the commitRecords() call on the store
-    @returns {Boolean} YES if handled
-  */
-  updateRecord: function(store, storeKey, params) {
-    return NO ;
-  },
-
-  /**
-    Called from retrieveRecords() to retrieve a single record.
-    
-    @param {SC.Store} store the requesting store
-    @param {Array} storeKey key to retrieve
-    @param {String} id the id to retrieve
-    @returns {Boolean} YES if handled
-  */
-  retrieveRecord: function(store, storeKey, id) {
-    return NO ;
-  },
-
-  /**
-    Called from createdRecords() to created a single record.  This is the 
-    most basic primitive to can implement to support creating a record.
-    
-    To support cascading data stores, be sure to return NO if you cannot 
-    handle the passed storeKey or YES if you can.
-    
-    @param {SC.Store} store the requesting store
-    @param {Array} storeKey key to update
-    @param {Hash} params to be passed down to data source. originated
-      from the commitRecords() call on the store
-    @returns {Boolean} YES if handled
-  */
-  createRecord: function(store, storeKey, params) {
-    return NO ;
-  },
-
-  /**
-    Called from destroyRecords() to destroy a single record.  This is the 
-    most basic primitive to can implement to support destroying a record.
-    
-    To support cascading data stores, be sure to return NO if you cannot 
-    handle the passed storeKey or YES if you can.
-    
-    @param {SC.Store} store the requesting store
-    @param {Array} storeKey key to update
-    @param {Hash} params to be passed down to data source. originated
-      from the commitRecords() call on the store
-    @returns {Boolean} YES if handled
-  */
-  destroyRecord: function(store, storeKey, params) {
-    return NO ;
-  }  
-    
-});