[Dev] Comments on Observable Queries Re: Dev digest, Vol 1 #186
- 1 msg
Brian Douglas Skinner
skinner at osafoundation.org
Mon Sep 29 18:21:48 PDT 2003
Thanks for reviewing the Observable Queries proposal!
Yes, I agree, the observer/observable model could be used for that
scenario, provided there is an aggregate "Calendar model" that the view
code can observe. But I think in the Chandler world, there may not also
be a one-to-one mapping between views and model objects. The calendar
views won't always be a window onto just the calendar model, but might
also be used to show other types of items. For example, Chandler might
make it possible to use a calendar month view to show e-mail messages,
organized by date received. In general, any Chandler view just shows a
collection of items, where that collection of items is the result of
some query. The only thing the items have in common is that they all
got included in the query result set. So generally speaking, there's no
single model object that unites all the items, and there's nothing for
the view to observe except the individual items, or the query itself.
But in the case where there is a calendar model object, the
observer/observable pattern would work. In a way, that
observer/observable solution is similar to the Observable Queries
solution. Broadly speaking, both cases have the same general flow of
events. First there's some small change to a single appointment item,
and that change leads to some simple notification, and that notification
is noticed by some filter, and the filter decides that it cares about
the change, and the filter notifies the view code.
The observer/observable solution and the Observable Queries solution
mostly just differ in where the filtering is done. In the Observable
Queries solution, all the filtering is encapsulated in the query, and
the view code only depends on the Query API. Whereas in the
observer/observable solution the filtering is split into two parts.
First the Calendar model notices the change to the appointment item, and
the calendar model applies a filter to decide that the appointment
change constitutes a change to the calendar as a whole. And then the
view code gets notified that there's been some kind of change to the
calendar model, and the view code then filters that info to decide if
the change has any impact on the one day that it is displaying. Or,
alternatively, the view could punt on doing that filtering and instead
just resubmit the query and redraw everything.
I like the Observable Queries pattern better, because it encapsulates
the filtering chore, and keeps all the filtering out of the view code.
If all the filtering is in the Query itself, behind the Query API, then
it becomes an implementation detail as to whether the filtering is done
on the client or done on the server. And it becomes an implementation
detail as to whether the Query even does filtering at all. At one
extreme, the Query could have filtering coded in some extremely clever
optimized way, whereas at the other extreme there could be no filtering
code at all, and the Query could simply do brute force periodic polling.
Andrew Francis wrote:
>>Brian Skinner is maintaining a Help Us! page on the
>>Chandler Wiki. This page is for small,
> self->contained, projects with clear deliverables
>>which would help OSAF enormously.
> I read the "Observable Queries Prototype" section
> and the beginning of the "Observable Queries" pages.
> I have comments on the following scenario.
> BS>"Question: Let's say the user has two views, a
> BS>Day View that shows Thursday, and a Week View
> BS>that shows the whole week. Suppose the user, in
> BS>Week View, drags a "Lunch" event from the Wednesday
> BS>column and drops it on the Thursday column. How
> BS>does the separate Day View find out that it needs
> BS>to display the "Lunch" event?"
> BS>observer/observable: In scenario 1 we used a
> BS>simple "observer/observable" mechanism to register
> BS>interest in individual objects, but that won't
> BS>work now. In scenario 2, the Day View has never
> BS>displayed the "Lunch" event before, and has never
> BS>registered as an observer, so it is never notified
> BS>of the edit.
> I sketched out your example and I don't see why an
> observer/observable model could not handle the
> aforementioned scenario. In the observer/observable
> model, I would suspect that the Week and Day View
> would be registered to declare their interest in
> changes to the Calendar model's state.
> When an end-user drags a lunch event from Wednesday
> to Thursday, this translates into the Calendar being
> updated and some type of update notification (event)
> being generated and sent to the observers. The
> update notification could either contain information
> about the state change, or can be a signal for the
> observers to fetch the appropriate Calendar state
> In the case of the Day viewer, the viewer would
> respond by grabbing information about Thursday events,
> (since that is what it is currently viewing) and
> would consequently display the new Lunch event. If
> the viewer was smarter, it may check the Calendar
> against its internal representation to see if things
> have indeed changed.......
More information about the Dev