[Cosmo-dev] CosmoUI Data Model Proposal

[Matthew Eernisse]

1. "For every type of stamp, we have different stamp prototype, like 
EventStamp, MessageStamp, TaskStamp."

Just to clarify terminology -- since there is already an actual 
'prototype' property of every object in JS -- and more importantly, JS 
objects can only have a single prototype, calling these 'prototypes' is 
probably not the right thing. Crockford uses the word 'pseudo-class,' 
which is kind of ugly, but I haven't seen anything better come along yet.

2. Stamps are stored as a property of each Item

If I understand this correctly, it looks like during the setup, you need 
to instantiate an empty stamp object as the value of the hash. Maybe a 
convenience method could just set it all up for you in one go? Something 
like this:

Item.prototype.OSAFSTAMPNAMESPACE =
     'really.super.long.namespace.for.stamps';

Item.prototype.addStamp = function (s) {
     var stampKey = this.OSAFSTAMPNAMESPACE + '.' + s;
     var stampConstructor = window[key];
     this.stamps[stampKey] = new stampConstructor();
};

Item.prototype.getStamp = function (s) {
     var stampKey = this.OSAFSTAMPNAMESPACE + '.' + s;
     return this.stamps[stampKey];
};

var thingie = new Item();
thingie.addStamp('Event');
var eventStamp = thingie.getStamp('Event');

My preference would be to have a single getStamp method rather than 
defining a separate convenience method for each and every type of stamp. 
You could add a bit of smarts in there so the key isn't case sensitive, 
if you wanted to.

3. StampAttribute

Really nicely done -- I like the idea of keeping the validator there. 
One other thing we might consider adding as a property is any custom 
'diff' function used to detect changes for that attribute.

Also, given the complexity of the form layout (horizontal, vertical, 
item groupings), I'm not sure how much utility the displayOrder property 
will be.

4. Other questions

This doc doesn't address the question of where the stuff we currently 
use like sort order, event conflict information, and so on would go.

I'm guessing that since that's mostly view-specific, we'll be 
maintaining sorted/filtered lists (Hash, some sort of collection, 
whatever) in the various views that point to the Items that are also in 
some central list. Is that what you're thinking?

Good stuff, very nice work.


Matthew


Bobby Rullo wrote:
> Methods schmethods. I'll try and get some of those in too.
> 
> Ideally, I'd like mde's input before going forward...
> 
> bobby
> On Mar 15, 2007, at 4:59 PM, Ted Leung wrote:
> 
>> Ok,
>>
>> This looks good.  I see properties/fields.   What about methods?   
>> Also, are there any other outstanding concerns on this besides me?   
>> What do we need to do to get to closure on these proposals?
>>
>> Ted
>>
>> On Mar 15, 2007, at 11:30 AM, Bobby Rullo wrote:
>>
>>> I updated the data model proposal with some object modelling and a 
>>> new bit about metadata.
>>>
>>> On Mar 13, 2007, at 4:49 PM, Ted Leung wrote:
>>>
>>>> On Mar 13, 2007, at 8:55 AM, Bobby Rullo wrote:
>>>>
>>>>> Here's my proposal for the data model in Cosmo UI:
>>>>>
>>>>> http://wiki.osafoundation.org/Projects/CosmoUIDataModelProposal
>>>>>
>>>>> Still need to work on the implementation section, but the general 
>>>>> idea is there.
>>>>
>>>> So after 1.5 readings:
>>>>
>>>> I'm not clear on whether there are objects that represent 
>>>> collections or not.  On the one hand, you show methods being invoked 
>>>> on an object name collection.  On the other hand, you say that 
>>>> collections are properties of Items, and that changing collections 
>>>> just requires updating that property.
>>>>
>>>> I don't see anything that I disagree with, but it feels like there 
>>>> needs to be an additional level of detail.  It would probably help 
>>>> to see some "class" definitions or use of proposed API's.
>>>>
>>>> Ted
>>>> _______________________________________________
>>>> cosmo-dev mailing list
>>>> cosmo-dev at lists.osafoundation.org
>>>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>>>
>>
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
> 
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>