**** BEGIN LOGGING AT Wed Nov 19 02:59:59 2014 Nov 19 03:45:24 sugardave , it’s our custom db8Source which talks to DB8, and would receive watch messages. It’s a Source, so it normally communicates by sending records to the callbacks passed to it. Source -> Store -> Collection Nov 19 03:46:01 If Sources were allowed to call set() on Models, why would they use the success callback at all? Nov 19 03:48:38 And it’s usually a Collection which is passed to db8Source. It would be very odd for it to send some results via the success callback, and others via fishing Models out of the Collection, and poking them directly. Nov 19 15:37:52 DougReeder: Still having problems with bound variables? Nov 19 15:55:54 the code is doing what I need it to do, Roy__ , but it’s inelegant to fire an event from a transform function. Nov 19 15:57:01 https://gist.github.com/DougReeder/7c49503f531fb6a59d51 Nov 19 15:58:23 So far as I can tell, only the transform function knows when data is flowing from the target to the source. Nov 19 15:58:46 Yeah, that's not good practice. Nov 19 15:58:56 What version of Enyo are you using? Nov 19 15:59:00 2.4 Nov 19 15:59:34 Ah. Nov 19 15:59:37 Hmm. Nov 19 16:00:03 Then that might be your only hope. I am not positive that observers were present in 2.4 Nov 19 16:00:14 Otherwise you could observe the model for changes. Nov 19 16:01:15 Your other choice is to undo the two-way binding and have an observer on the favorite. Nov 19 16:01:47 Why do you need to fire the event? Nov 19 16:01:48 The complication is that person is often changing. I’d have to attach an observer to its favorite property every time it changes, and remove the old observer. Nov 19 16:02:08 … which is doable, but complicated Nov 19 16:02:39 When the user toggles the “favorite” control, the model needs to be committed. Nov 19 16:02:56 … and a collection needs to be refiltered. Nov 19 16:04:08 Can't you just set the model to commit on change? The filter should also update automatically when a model in it changes. At least, it does in 2.5 I'm pretty usre. Nov 19 16:04:13 *sure. Nov 19 16:06:30 “set the model to commit on change” - I don’t know what you mean by that - one can observe prperties on=f a model, or when the whole model is replaced by another one, but I’m not aware of any way to observe “any property of a model has changed" Nov 19 16:09:23 … and I still need to refilter a collection when the favorites property changes Nov 19 16:11:27 Data binding works great when all you need to do is copy (and possibly xform) a value from one place to another, but there doesn’t appear to be a graceful way to copy-value-and-do-this-other-thing. Nov 19 16:13:07 Models have a 'change' event you can subscribe to (at least in 2.5 using the Observer mixin) Nov 19 16:13:16 It will fire for any change to a model. Nov 19 16:13:34 model.on("change", myFunction) Nov 19 16:14:54 That would be of value, but itsounds like I’d still have to attach the observer to each model, when it was selected. Nov 19 16:15:26 The app is the Contacts app in LuneOS - it should be functionally identical the Contacts app in webOS 3.0.5 Nov 19 16:16:33 So there’s two DataLists, each backed by a PersonCollection of PersonModels. Nov 19 16:17:11 You can observe the collection and see when a model changes. Nov 19 16:17:47 When you tap on a person in the list, it sets the pusblished person property of the ContactDetails pane. Nov 19 16:17:59 * @property {Boolean} commit=false - Immediately [commit]{@link enyo.Model#commit} changes Nov 19 16:17:59 * after they have occurred. Also note that, if `true`, when the [model]{@link enyo.Model} Nov 19 16:18:25 * is [destroyed]{@link enyo.Model#destroy}, it will also be destroyed via any Nov 19 16:18:25 * [sources]{@link enyo.Model#source} it has. Nov 19 16:18:51 So, if you set it to commit: true it will save itself. Nov 19 16:19:02 Same for collection. Nov 19 16:19:09 http://enyojs.com/docs/latest/api/#enyo.Collection says “Collection objects generate add, remove, reset and destroy events that may be listened for using the addListener() method.” Do any of those fire when properties of a model fire? Nov 19 16:19:23 er, fire when properties of a model change? Nov 19 16:20:38 (That commit is on the options hash, if I wasn't clear on thaT) Nov 19 16:22:00 Collections will pass through change or destroy events from models. Nov 19 16:22:05 I’m not seeing an options hash for the collection as a whole, just on individual methods. Nov 19 16:22:27 Might be a 2.5 feature. Models and Collections both have a default options hash. Nov 19 16:22:52 2.5 has vastly improved data handling Nov 19 16:23:17 Destroy is not actually sent out as an event. I take it back. But you will get a length change event. Nov 19 16:23:35 Okay, Collection has a recordChanged property Nov 19 16:23:54 When a model changes the listener will get the model as a paramter. Nov 19 16:23:56 parameter Nov 19 16:30:13 I think implementing the PersonCollection’s recordChanged method would do what I want. Nov 19 17:13:17 I hope that helped. Nov 19 17:26:01 \o/ Roy__ saves the day! Nov 19 20:12:30 Hey, since the build tools use Node, gitinfo might come in handy: https://github.com/gajus/gitinfo Nov 19 20:13:55 I’m thinking it might be possible to detect that a more stable version of enyo or some library is available. Nov 19 20:15:10 Or maybe something more mundane, like the build tool reporting that you’re using a branch other than master. **** ENDING LOGGING AT Thu Nov 20 02:59:58 2014