r12 - 13 Jul 2007 - 05:49:07 - MimiYinYou are here: OSAF >  Projects Web  >  CosmoZeroDotSeven > CosmoUIDataModelProposal

Cosmo UI Data Model Proposal

Introduction

The Cosmo UI (née Scooby) was designed to handle just calendaring functionality. Now we want to extend the Cosmo UI to support more of the functionality of Chandler, such as handling tasks and displaying a dashboard. As such we need to modify the current data model to accommodate the new data types and some of the Chandler specific concepts such as stamping. In doing so it is expected that this data model will come to resemble Chandler's and Cosmo's. There will some differences in the models due idiosyncrasies of programming languages and programming environments, but we hope to capture the essentials. Areas where we deviate significantly will be highlighted elsewhere in this document.

Requirements

The following are explicitly required by dashboard functionality:

  1. Support for "Generic" items
    • This means that a collection is a bag of items of various types which may include events, tasks and messages and other types.
  2. Support for Stamping
    • This means that an item has various sets of attributes which give it its "is-ness", and that an item can be stamped with more than one set of attributes, so something can be both an event and a message and a task.
  3. Support for Items in multiple collections
    • Items living in more than one collection is a key feature of the Chandler Data model

These next items are required due to implications caused by the above:

  1. Revised Permissions Model
    • Right now permissions are very simple and based on the collection that an item is in. Obviously now this will have to change due to the fact that items can live in multiple collections, each potentially having a different permission level
  2. Metadata For Stamps
    • Stamps should have metadata about the types of properties in the stamp so that editing panes can be dynamically created

Proposal

Item/Stamping Support

All Items are instances of a single Item type
Instead of having an Event type and a Task type and a Message type, we will have one single Item type which has the common properties of all item types (uid, name, date created, date modified, etc.)

Stamps hold type-specific properties
For every type of stamp, we have different stamp prototype, like EventStamp?, MessageStamp?, TaskStamp?. Each Stamp prototype has metadata about the stamp (more on that later...) like the unique namespace of the stamp, and metadata about the properties in a stamp.

Stamps are stored as a property of each Item
Stamps are stored in a hash on each item called stamps. The key of the hash is the name space of the stamp (all stamps have a unique namespace.) Of course having to type item.stamps['org.osaf.really.long.namespce'].startDate is inconvenient, so there will be some convenience methods for getting certain stamps like item.getEventStamp(), item.getMessageStamp() etcetera.

Each Stamp is self-descriptive Stamp types have metadata which will include information about the stamp's namespace as well as information about each of the attributes that the stamp contains. This way, for example, the detail view will be able to dynamically draw the form info for any stamp, as the attribute information will contain data about the type of the attribute, a validator, the order it should appear in a form, etc.

Items in multiple collections

Collections are a property of an Item
The uid's of the collections that an item belongs to and which the user has access to (either through subscriptions or belonging to the user) are stored as a property of each item.

Changing collections is Simple
Adding an item to or removing an item from a colleciton is as simple as adding or removing that collections uid to the item's array of collection ids.

Persistence

(note: some of this is covered in XXXXXXXXX)

Items and Collections are smart
To get the items in a collection, you call a method on the collection like collection.getEvents(startDate, endDate). To save an item you call item.save(). Almost any method that requires client/server communcation and operates on collections or items are available as methods of items or collections.

The smarts are in the Collections
When data is deserialized from the server collections will get injected with something (still being discussed) which gives it enough information to know how to perform client/server operations. This could be a "conduit" - an object with methods and data for using a particular data source or a "transport info" object - just a data object with credentials (name, pw, ticket, etc.) which the model object would pass to the service.

Items use the Permissions of the least restrictive collection
Since an item can belong to various collections, each having different permissions policies, when tryiing to make a change to an item (including deleteting an item) the save method will cycle through the collections it belongs to until it finds one permissive enough, and then attempt to save using the "conduit" (or "transport info" or "data source" - TBD) of that collection. note - there is still some discussion on the list w/r/t this issue.

Recurrence instances are not "real" items
Items which recur (right now only items stamped as events) need to be able to provide the expanded-out instances of themselves for a given time-range. In addition, we need to be able to get from a collection all the events that occur in a given time-range, including non-recurring events, the master event of a recurring event, and any instances of a recurring event. Items which are instances will have a boolean property called "instance" set to true. Items that are instances cannot have any of their client/server methods called - attempting to do so will result in an exception. If you want to make a change to an instance, find the master item, make the appropriate changes there and save the master event. This is more or less what we already have.

Implementation

Class Hierarchy

Object Properties

BaseModelObject

Type Static Name Notes
String   uid  
String   name do we need this  
String   displayName  
Integer   version  
Date   creationDate  
Date   modifiedDate  
Date   clientCreationDate do we need both of these
Date   clientModifiedDate do we need both of these


Collection
Type Static Name Notes


Item
Type Static Name Notes
Map (keys: stamp namespace, value: stamp)   stamps  


BaseStamp
Type Static Name Notes
StampMetaData? yes stampMetaData  


StampMetaData
Type Static Name Notes
String   namespace the namespace which uniquely identifies this type of stamp
StampAttribute?[]   attributes array of the attributes that this type of stamp contains


StampAttribute
Type Static Name Notes
String   name the name of the attribute
Function   validator a function which validates the attribute
Enum   type the type of the attribute (could be date, timezone, string, integer, float, etc.)
int   displayOrder the order in which to display the fields in a form



EventStamp

  • More or less same as existing "Event" object



TaskStamp

Type Static Name Notes
       
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r12 < r11 < r10 < r9 < r8 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.