On Thu, 24 Feb 2011 10:15:29 Francis J. Lacoste wrote: > Hi Tim, > > This looks really great! And the hook up is very palatable! > > > One question on the hook-up: any specific reason to do one global event > containing all the changes, instead of one event per change? Instead of > subscribing to lp:context:changed event, subscribing to > lp:context:web_link:changed ? So that call sites don't have to parse the > changed_fields? Or even more struture, have the cache JSON object be proper > Attribute-based object on which we could subscribe on the fooChange event > (http://developer.yahoo.com/yui/3/examples/attribute/attribute-event.html)?
I did consider a field by field update event, but there is always the possibility that a particular page my have conditional updates, and I got convinced not to. We could trivially add field by field update events as well as an event for the entire object. That way if you are writing a page that you know may have a race condition, you could listen on the object updated rather than the field updates. With respect to the attribute based objects, there are two issues around it: * Firstly due to my lack of knowledge of its existance * Secondly, the cached objects are simple Javascript objects that are not held in any YUI sandbox. The exist outside of YUI. Tim _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
