Commit graph

2 commits

Author SHA1 Message Date
Dan Stillman
70630a2e70 - Change: Scholar.Notifier.trigger() can be passed an array of ids in some cases rather than a single id -- trees that implement notify() should use Scholar.flattenArguments(ids) to get an array either way
- Added Notifier triggers to Item.erase() (which only runs if not in a nested transaction) and Collections.erase()

- notify() in ItemTreeView updated with example of taking multiple ids, though it doesn't actually work (and notify() implementations may decide just to refresh the whole tree when ids.length>1 rather than dealing with changes individually)

- When deleting collections, use DB tables that actually exist
2006-06-01 22:19:21 +00:00
Dan Stillman
38d87463af Item.inCollection(collectionID) -- test if an item belongs to a given collection (currently uses a DB call--I'll optimize that later)
Scholar.Notifier framework to handle update notifications between data layer and interface

 - Notifier.registerColumnTree(ref) and Notifier.registerItemTree(ref) pass back a unique hash that can be used to unregister the tree later with unregister*(hash) (and must be, lest we leak treeViews and probably entire browser windows if the browser window is closed without unregistering the treeView)

 - Data layer calls Scholar.Notify.trigger(event, type, id) after various events (only two calls in the data layer at the moment--more coming later)

 - Notify.trigger() calls notify(event, type, id) on all registered trees of the appropriate type -- the data layer usually knows what collection the action pertains to, but we decided that it's cleaner to just let the tree decide what it wants to do rather than add all that logic into the data layer)

 (Note: Item collection adds appear to be buggy on the interface side, but removes seem to be working)
2006-06-01 20:03:53 +00:00