[Cosmo-dev] Cosmo WebUI Service Layer

[Travis Vachon]

>> This is shorthand for "get an Item and assign it my conduit." I  
>> hadn't really thought about it, but this actually goes a little  
>> beyond the "syntactic sugar" idea of MDCS. That said, I think it  
>> is a _very_ common idiom, and we probably want to keep it. Getting  
>> an Item with only a UID requires picking a Conduit through which  
>> to get it, and should be done at the Conduit level.
>
> I understand the shortcut, but why is it at the collection level if  
> items don't belong to collections?

Actually, I rethought this, Collection.getItem(uid) is actually  
shorthand for

Collection.getConduit().getItem(uid)

so it fits perfectly with the idea of syntactic sugar. It's at the  
Collection level because _that's_ how it knows which conduit to use.  
Otherwise, the user (UI code) will need to specify a Conduit.
>
>>>
>>>> The Conduit API will be stable enough for business object use.  
>>>> However, it is recommended that developers use the Model Data  
>>>> Convenience affordances whenever possible.:
>>>
>>> I'm thinking we should insist that other code only use the MDC  
>>> stuff.
>> The more I think about this the more I think it's a good idea.  
>> This means we'll need to find somewhere for _all_ Conduit methods  
>> to live. Here's a skeletal proposal:
>>
>
> Don't know what you mean by this...Why wouldn't we need a place for  
> them to live before? Or are you  responding to "where do you find  
> the current conduits"?
Sorry, this was poorly worded, what I really meant was "we'll need to  
find somewhere for the API that _uses_ that Conduit API to live (that  
is, the API that is used by the UI). In many cases, these will simply  
be functions that call methods on the DefaultCurrentUserConduit.
>
>> Create another module ("cosmo.service.*"?) that looks like:
>>
>> cosmo.service = {
>>
>> getCollections(){get collections using CurrentUserConduit},
>> getSubscriptions(){get subscriptions using CurrentUserConduit},
>> getPreferences(){get preferences using CurrentUserConduit}
>> ...
>> }
>>
>> this assumes some default place to find the CurrentUserConduit.  
>> Right now CurrentUserConduit is somewhere like  
>> cosmo.service.jsonrpc.CurrentUserConduit, but we could say that a  
>> default should be found at cosmo.service.DefaultCurrentUserConduit.
>>
>
> I don't think stuff like getCollections, getSubscriptions etcetera  
> need the conduit abstraction layer, since they can only be gotten  
> through one way. That is, you would never use a ticketed collection  
> conduit to get the user's preferences.
Well, I feel _very_ strongly that these things need to be in the  
Conduit layer somewhere. The Conduit layer is meant to be used for  
_all_ client-server interaction. The case you give is the reason that  
preference methods only appear in the CurrentUserConduit, and not   
the base level Conduit.
>
>>
>>> The MDC api is likely to be more stable, and I'd rather not have  
>>> to make the UI dev manually inject conduits into newly created  
>>> items/collections.
>> This will never be necessary, as the conduit injection will be  
>> done at the conduit level. Essentially, items will inherit the  
>> Conduit they were fetched over. I'll add  this to the proposal.
>>
>>>
>>>> item.doDelete()
>>>
>>> why not "delete()"?
>> delete is a keyword in Javascript, so I was worried this might be  
>> problematic. It appears ok to do this in Firefox, but we'll need  
>> to verify it's ok in other browsers too.
>>
> Oh ok. I prefer d3l3t3(). Not really.

d31337()

>>>
>>> Also, what do we do about "new" items? Does the conduit become  
>>> like an item factory - "var item = conduit.newItem()" ?
>>>
>> This is a model question, really. Unless we want to significantly  
>> change how the code currently works, I think sticking with the  
>> "create an item and use saveItem to make it appear on the server"  
>> idiom. It would probably make sense to have a method like
>>
>> Collection.newItem(){create an Item that inherits my Conduit}
>
> Well, it's not really just a model question anymore, since you  
> decided to get your cookies in my peanut butter - i.e. give the  
> items some smarts.
Heh, true enough. Does this syntax work? If we really want to support  
Items outside of Collections someday in the future, we'd probably  
need something similar to what we're talking about for Collections  
below:
>
>>>
>>> But then how do you get a new collection?
>>
>> var c = new Collection([conduit, ticketKey])?
>
> Don't like the inconsistency - using a construtor for collections,  
> but a factory method for items? And ewwww with ticketKey being in  
> the constructor for a collection. Collections know nothing about  
> ticketkeys - subscriptions do, and conduits do.
>
> I was thinking:
>
> var newCollection = someConduit.newCollection()
This is actually exactly what I was thinking initially, this is an  
example of UI/business code calling the Conduit layer.

Perhaps cosmo.service.newCollection(), where the call knows to use  
the DefaultCurrentUserCollection?
>>
>>>
>>> Also, how does the one (if one can) get a handle on the list of  
>>> conduits that are "loaded"?
>>
>> Yeah, we should probably have something along these lines for the  
>> TicketConduits, at the very least so that we don't create multiple  
>> TicketConduits for the same Ticket. Perhaps  
>> TicketConduitFactory.getConduit(ticketKey) would suffice?
>>
>
> I think a TicketConduitFactory is more abstraction than we need.  
> Why not just some methods like:
>
> cosmo.conduits = {
>
>     getConduits: function() { //return all the conduits known to  
> this user}
>     getSubscriptionConduitByTicketKey: function(){//what you said}
>     getTicketConduitByTicketKey: function(){//what you said}
>     getLoggedInUserConduit: function(){ //returns the  
> LoggedInUserConduit singleton}
>
> }
That, or something very similar, would work like a charm.

-Travis