READ THIS if you use the observer APIs ...

Question

This is just a heads up for developers who take advantage of
the observer APIs in Spry. For the next version of Spry I plan on
making the observer APIs for both the Data Set and the Dynamic
Region consistent.
Currently in Spry PR 1.1 the data set observer mechanism
requires that you register an object with an onDataChanged method
on it. This method is then called with a notification type
(Spry.Data.DataSet.ODC_*) which developers have to manually check
against and conditionally perform their action.
In Spry PR 1.1, the observer mechanism used for the dynamic
region requires that you register a callback function, which gets
passed a region state (Spry.Data.Region.RS_*) whenever it is
called, and it is up to the developer to check against the region
state and conditionally perform their action.
For the next release of Spry, I plan to move to the following
model:
- Both data set and region observer mechanisms will require
an object which defines notification methods for which it wants to
be notified for.
// Create an object with notification methods.
var myObserver = new Object;
myObserver.onDataChanged = function (notifier, data) {
alert("OnDataChanged called!"); };
// Register your object as an observer on the data set.
dsMyDataSet.addObserver(myObserver);
- Notification methods will all have the same signature:
function (notifier, data) {}
The notifier is the object that is dispatching the
notification, and the data is an object that will contain
information regarding the notification, where necessary, or
undefined if no additional data is necessary for the notification.
When called, the 'this' object within the notification method
will be the actual observer object.
- We will publish a list of notification methods that can be
defined on the observer object for both the data set and dynamic
region.
- *All* methods on the observer object are *OPTIONAL*, which
means you only have to define the notification methods that you
want to be called for. For example:
var observerA = new Object;
var observerB = new Object;
observerA.onDataChanged = function (notifier, data) {
alert("observerA.onDataChanged called!"); };
observerA.onSortChanged = function (notifier, data) {
alert("observerA.onSortChanged called!"); };
observerB.onDataChanged = function (notifier, data) {
alert("observerB.onDataChanged called!"); };
myDataSet.addObserver(observerA);
myDataSet.addObserver(observerB);
In the example above both observerA and observerB will be
called whenever the data changes, but only observerA will be
notified whenever a sort happens.
- Some events will have pre and post notifications. For
example onPreLoad(), onPostLoad(), onPreUpdate() and
onPostUpdate(), etc.
If you have any opinions, concerns or feedback on this. Now
would be the time to speak up.
--== Kin ==--

Answer 1

As one person who asked for this, I like what your planning.
Is that onPreLoad() an event that will get fired before an Ajax
request goes out for new data? Cuz I could really use that.
A tagentally related thought: Notifications are great, but in
some cases, I might want to control whether some behavior happens.
Say, perhaps I want to control whether the load actually happens.
In that case, I'd want a delegate object, which would have some
methods on it that could cancel the event that is going happen.
Just as an example:
var delegate = {
willFireLoad: function(...) { if (somecondition) return
false; else return true; },
unknownValueForKey: function(key, dataset) { ... return
dynamic value ... },
unknownValue_desc: "Description"
dataSet.setDelegate(delegate);
The first would allow me to stop the data from being loaded.
The second would allow me to return a value for a key that isn't
present in the dataset. And the third could be a way to hardcode a
value for the key 'desc'.
Just kinda an idea as far as what could be done, and I'm sure
there might be other control points too.
-d