**** BEGIN LOGGING AT Mon Nov 17 03:00:00 2014 Nov 17 03:06:02 Hey, is the minifier used by enyo smart enough to toss out unused parameters? For example, I have a function searchTextChanged: function (inOldSearchText) {…} but I don’t actually use inOldSearchText. Will the enyo minifier rewrite that as a function with *no* arguments? Nov 17 14:39:41 Model.parse allows you to transform on read. Is there a parallel method to transform on write? includeKeys is used by raw and toJSON, but are we guaranteed that commit calls them? Nov 17 16:47:22 DougReeder: No, it's not that smart. Nov 17 16:47:33 It's uglifyjs, iirc. Nov 17 16:47:38 So, see what it can do. Nov 17 16:47:51 * DougReeder nods Nov 17 16:54:30 #dougreader: can you override the commit function? Nov 17 17:15:35 Hmm, override commit. Nov 17 17:16:14 Does collection.commit call Model.commt ? Nov 17 17:17:18 morning enyos Nov 17 17:18:02 if i remember correctly, collection individually commits models. Nov 17 17:22:51 It looks like my Source uses raw(), so I should probably exclude fields using includeKeys. Nov 17 17:24:19 dmanderson: can you point me to a good documentation on how to write a JSDoc template? I need to convert JSDoc to reST and the only 2 templates I can find don't work for one reason or another Nov 17 18:57:33 dmanderson: ?_? Nov 17 18:59:19 Hmm, I don’t know of any really good documentation :-/ Nov 17 18:59:40 damn Nov 17 21:32:32 Is Source.commit() expected to return the object or model that was committed? Nov 17 21:35:59 Model.parse() gets called after a commit, with an object that appears to be the return value from commit() Nov 17 22:26:10 Okay, in line 400 of Model.js, didCommit unconditionally calls parse(res), with the response from Source.commit() Nov 17 22:28:12 That’s problematic - Source.commit() may not return the value of the object, and parse shouldn’t need to distinguish between being called after a fetch and being called after a commit. Nov 17 22:31:24 as i understood it, the commit (or didCommit) gets a result back from server, which is expected to be the same format that fetch gets it...hence, it calls parse on it... Nov 17 22:34:17 a fetch that didn’t return records wouln’t be a fetch, but a commit that accepts records, but doesn’t return them, seems perferctly reasonable to me. Nov 17 22:35:38 Yeah, you can hack up Source.commit to return the data it was passed, but why should you need to? Nov 17 22:36:58 That’s not a standard feature of CRUD models. Nov 17 22:39:12 keine ahnung Nov 17 22:39:16 :( Nov 17 22:40:03 …and I shouldn’t need to read the source code to know what the contract between Source and Store is. Nov 17 22:53:10 :) Nov 17 23:05:15 DougReeder, I don't understand the problem you're having. Nov 17 23:06:32 As Cage1___ said, Source#commit returns the response from your Store. This is assumed to be the newly updated model data. Nov 17 23:07:01 ergo, parse doesn't need to distinguish between fetch and commit Nov 17 23:07:18 it's assumed your datastore is sane Nov 17 23:08:17 In my application, the database (DB8) doesn’t return records passed in. Nov 17 23:08:43 And most of the APIs I’ve used don’t pass back the data you just passed in. Nov 17 23:09:12 I can rework our custom Source to return the data passed in. Nov 17 23:09:33 … but neither the docs nor examples say you need to. **** ENDING LOGGING AT Tue Nov 18 02:59:59 2014