This document assumes that we will continue to use JSON-RPC.
Why
Why do we have to do a bunch of plumbing work for 0.7?
- Dashboard will have new datatypes that are not currently supported
- Different widgets will have views to the data concurrently and we need a way to handle this
- The current system of handling exceptions is a bit onerous and leads to repeated code.
- The data model lacks some things we need (versions, modified date, stamps, etc.)
What
Model Changes
- Add new types to data model
- Support Stamps
- I'm afraid that this might mean stuff like accesing the start date of an event would look like "item.stamps.event.startDate", but it might be neccesary otherwise you have properties that might conflict.
- Consider a common ancestor for all items
- would have version, uid, etc.
- stamps prop? other common things?
- Consider changing from a Anemic Domain Model to a Rich(er)Domain Model
Client/Server Changes
- Create a layer between "raw" service calls and UI
- this layer would:
- handle errors by publishing them on a Topic
- deal with all the different "conduits"
- publish topics for all model events like
- trySaveItem
- suceedSaveItem
- failSaveItem
- possibly handle the display of service related errors (i.e. alerting the user) so that the each ui widget that saves doesn't have to handle say "ConcurrencyException" or other common server side errors. The ui elements would just then be responsible for cleaning up after he failed save.
Collection Wallet
- This is the object that contains the currently available collections
- Right now is just a hashtable, has no API
- needs a better api, centralized location (same strucutre is currently living in two places right now for no good reason
- could serve as the "repository" for items - if you want an item, you go here. (resuse some of mde's repo code?)
- this sets us up good for caching of items, offline storage, etc.
How
Works in Progress
- Thoughts? on changing to a rich data model.
- Notes? on model changes
- Notes? on changes to client/server stuff.