sproutcore 1.5.0.rc.1 → 1.5.0.rc.2

data/lib/frameworks/sproutcore/frameworks/core_foundation/views/view/layout.js

@@ -179,23 +179,23 @@ SC.View.reopen(
     The layout describes how you want your view to be positions on the
     screen.  You can define the following properties:
 
-    - left: the left edge
-    - top: the top edge
-    - right: the right edge
-    - bottom: the bottom edge
-    - height: the height
-    - width: the width
-    - centerX: an offset from center X
-    - centerY: an offset from center Y
-    - minWidth: a minimum width
-    - minHeight: a minimum height
-    - maxWidth: a maximum width
-    - maxHeight: a maximum height
-    - border: border on all sides
-    - borderTop: top border
-    - borderRight: right border
-    - borderBottom: bottom border
-    - borderLeft: bottom left
+     - left: the left edge
+     - top: the top edge
+     - right: the right edge
+     - bottom: the bottom edge
+     - height: the height
+     - width: the width
+     - centerX: an offset from center X
+     - centerY: an offset from center Y
+     - minWidth: a minimum width
+     - minHeight: a minimum height
+     - maxWidth: a maximum width
+     - maxHeight: a maximum height
+     - border: border on all sides
+     - borderTop: top border
+     - borderRight: right border
+     - borderBottom: bottom border
+     - borderLeft: bottom left
 
     Note that you can only use certain combinations to set layout.  For
     example, you may set left/right or left/width, but not left/width/right,
@@ -221,10 +221,8 @@ SC.View.reopen(
     other words, if you want to convert the frame of your view to the global
     frame, then you should do:
 
-    {{{
-      var pv = this.get('parentView'), frame = this.get('frame');
-      var newFrame = pv ? pv.convertFrameToView(frame, null) : frame;
-    }}}
+        var pv = this.get('parentView'), frame = this.get('frame');
+        var newFrame = pv ? pv.convertFrameToView(frame, null) : frame;
 
     @param {Rect} frame the source frame
     @param {SC.View} targetView the target view to convert to
@@ -263,10 +261,8 @@ SC.View.reopen(
     parentFrame.  For example, if you want to convert the frame of view that
     belongs to another view to the receiver's frame you would do:
 
-    {{{
-      var frame = view.get('frame');
-      var newFrame = this.convertFrameFromView(frame, view.get('parentView'));
-    }}}
+        var frame = view.get('frame');
+        var newFrame = this.convertFrameFromView(frame, view.get('parentView'));
 
     @param {Rect} frame the source frame
     @param {SC.View} targetView the target view to convert to

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

@@ -16,23 +16,21 @@ sc_require('data_sources/data_source');
   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
+  ## 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(),
+      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" })
+        
+      });
       
-      prefs:   MyApp.PrefsDataSource.create({ root: "/prefs" }),
-      youtube: YouTube.YouTubeDataSource.create({ apiKey: "123456" }),
-      photos:  MyApp.PhotosDataSource.create({ root: "photos" })
-      
-    });
-    
-    MyApp.store.set('dataSource', MyApp.dataSource);
-  }}}
+      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.
@@ -40,14 +38,12 @@ sc_require('data_sources/data_source');
   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.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);
-  }}}
+      MyApp.store.set('dataSource', MyApp.dataSource);
 
   In this case, the order you call from() will determine the order the request
   will cascade.

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

@@ -13,60 +13,45 @@
   and implement the necessary data source methods to communicate with the 
   particular backend. 
   
-  
-  h2. Create a Data Source
+  ## 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...
-  	});
-	}}}
+      MyApp.DataSource = SC.DataSource.extend({
+        // implement the data source API...
+      });
   
+  ## Connect to a Data Source
   
-	h2. Connect to a Data Source
-	
-	New SproutCore applications are wired up to fixtures as their 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')
-  }}}
+    // 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. 
   
+  ## Implement the Data Source API
   
-  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>
+  There are three methods that a data store invokes on its data source:
+
+   * `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.
+   * `retrieveRecords()` &mdash; called when you access an individual 
+     record that has not been loaded yet
+   * `commitRecords()` &mdash; called if the the store has changes 
+     pending and its `commitRecords()` method is invoked.
 
 	The data store will call the `commitRecords()` method when records 
 	need to be created, updated, or deleted. If the server that the data source
@@ -79,48 +64,39 @@
 	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
+
+   * `createRecords()` &mdash; called with a list of records that are new 
+     and need to be created on the server.
+   * `updateRecords()` &mdash; called with a list of records that already 
+      exist on the server but that need to be updated.
+   * `destroyRecords()` &mdash; called with a list of records that should 
+     be deleted on the server.
+
+  ### 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 
+	`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.
+	 - `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
+  ### 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.
+	 - `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  
+  ### 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
@@ -131,32 +107,21 @@
 	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>
+   * `readDataHash(storeKey)` &mdash; returns the data hash associated with 
+     a store key, if any.
+   * `readStatus(storeKey)` &mdash; returns the current record status 
+     associated with the store key. May be `SC.Record.EMPTY`.
+   * `SC.Store.recordTypeFor(storeKey)` &mdash; returns the record type for 
+     the associated store key.
+   * `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`.
 	
 	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
+	### 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 
@@ -181,35 +146,27 @@
 	record can be unlocked right away.
 	
 	
-	h3. Record-Related Callbacks
+	### 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
+   * `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.
+   * `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.
+   * `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. 
+	
+	### 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, 
@@ -221,7 +178,7 @@
 	the store, especially in response to a `fetch()` or `retrieveRecords()` call.
 	
 	
-	h3. Query-Related Callbacks
+	### 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 
@@ -229,29 +186,19 @@
 	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>
+   * `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. 
+   * `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. 
+   * `dataSourceDidCancelQuery(query)` &mdash; the data source should call this 
+     if loading the results is cancelled.
 	
 	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
@@ -272,7 +219,7 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
     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
+    ### 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.
@@ -289,7 +236,7 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
     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
+    ### 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 
@@ -307,7 +254,7 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
     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
+    ### 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
@@ -318,7 +265,7 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
     the query back into the state it was in previously before it started 
     loading the query.
     
-    h3. Return Values
+    ### 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
@@ -355,21 +302,21 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
     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
+     - `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 
+    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.
+    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
@@ -400,14 +347,14 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
     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.
+    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.
+    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
@@ -422,14 +369,14 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
   // 
   
   /**
-    Called from commitRecords() to commit modified existing records to the 
+    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.
+    `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.
+    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
@@ -445,14 +392,14 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
   },
   
   /**
-    Called from commitRecords() to commit newly created records to the 
+    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.
+    `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.
+    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
@@ -469,14 +416,14 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
   },
 
   /**
-    Called from commitRecords() to commit destroted records to the 
+    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.
+    `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.
+    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
@@ -518,11 +465,11 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
   // 
   
   /**
-    Called from updatesRecords() to update a single record.  This is the 
+    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.
+    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
@@ -535,7 +482,7 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
   },
 
   /**
-    Called from retrieveRecords() to retrieve a single record.
+    Called from `retrieveRecords()` to retrieve a single record.
     
     @param {SC.Store} store the requesting store
     @param {Array} storeKey key to retrieve
@@ -547,11 +494,11 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
   },
 
   /**
-    Called from createdRecords() to created a single record.  This is the 
+    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.
+    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
@@ -564,11 +511,11 @@ SC.DataSource = SC.Object.extend( /** @scope SC.DataSource.prototype */ {
   },
 
   /**
-    Called from destroyRecords() to destroy a single record.  This is the 
+    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.
+    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

data/lib/frameworks/sproutcore/frameworks/datastore/data_sources/fixtures.js

@@ -39,10 +39,10 @@ SC.FixturesDataSource = SC.DataSource.extend(
     here.  You should tune this to simulate latency based on the expected 
     performance of your server network.  Here are some good guidelines:
     
-    - 500: Simulates a basic server written in PHP, Ruby, or Python (not twisted) without a CDN in front for caching.
-    - 250: (Default) simulates the average latency needed to go back to your origin server from anywhere in the world.  assumes your servers itself will respond to requests < 50 msec
-    - 100: simulates the latency to a "nearby" server (i.e. same part of the world).  Suitable for simulating locally hosted servers or servers with multiple data centers around the world.
-    - 50: simulates the latency to an edge cache node when using a CDN.  Life is really good if you can afford this kind of setup.
+     - 500: Simulates a basic server written in PHP, Ruby, or Python (not twisted) without a CDN in front for caching.
+     - 250: (Default) simulates the average latency needed to go back to your origin server from anywhere in the world.  assumes your servers itself will respond to requests < 50 msec
+     - 100: simulates the latency to a "nearby" server (i.e. same part of the world).  Suitable for simulating locally hosted servers or servers with multiple data centers around the world.
+     - 50: simulates the latency to an edge cache node when using a CDN.  Life is really good if you can afford this kind of setup.
     
     @property {Number}
   */

data/lib/frameworks/sproutcore/frameworks/datastore/models/child_attribute.js

@@ -10,17 +10,15 @@ sc_require('models/record_attribute');
 
 /** @class
   
-  ChildAttribute is a subclass of RecordAttribute and handles to-one 
+  ChildAttribute is a subclass of `RecordAttribute` and handles to-one 
   relationships for child records.
   
-  When setting ( .set() ) the value of a toMany attribute, make sure
-  to pass in an array of SC.Record objects.
+  When setting ( `.set()` ) the value of a toMany attribute, make sure
+  to pass in an array of `SC.Record` objects.
   
   There are many ways you can configure a ManyAttribute:
   
-  {{{
-    contacts: SC.ChildAttribute.attr('SC.Child');
-  }}}
+      contacts: SC.ChildAttribute.attr('SC.Child');
   
   @extends SC.RecordAttribute
   @since SproutCore 1.0