[Cosmo-dev] Cosmo WebUI Service Layer

[Bobby Rullo]

>>
>> I would also like to see a way for the owner conduit and  
>> subscription conduit (and all other conduits which require login)  
>> to prompt the user to re-login if they've timed out and then  
>> automatically retry the request.
>>
> Agreed. I'm not sure this should go in the service layer, though. I  
> don't really like the idea of mixing ui code into the service  
> layer. Throwing an exception that ui code can handle, or that could  
> be handled by some useful error handling module, seems more  
> appropriate.

No, I am not talking about error handling in general - just this one  
specific error which we always want handled the same way I am pretty  
sure.

I agree 200% that mixing ui code into the service code is bad. Makes  
unit testing hard and creates unwanted dependencies.

I was thinking something more in the line of having a hook in the  
service layer for a callback for what to do for this specific  
exception (user not logged in or something). I'd rather not have to  
have the UI code handle this every time it makes a service call,  
instead it just registers at app startup this callback which pops a  
dialog to log the user in again and if successful tries again....

>>>
>>>  Model Data Convenience Syntax
>>
>> Looks ok, but still worried about this for some reason.
>>
>> Why does the collection object have a getItem()? Items don't  
>> belong to a particular collection and you can identify them solely  
>> with the UID.
> 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?

>>
>>> 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"?

> 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.

>
>> 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.
>>
>> 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.

>> For MDC we could do "var item = collection.newItem()"
> Heh, I just read this. Great minds... ;)

:-)


>>
>> 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()

>
> Where "conduit" and "ticketKey" are keyword arguments as described  
> in the proposal.
>
> If ticketKey is given, Collection's constructor will create/find  
> the appropriate ticket conduit. If "conduit" is given, the  
> Collection will be created with the given Conduit as its conduit  
> (but not saved!!). Otherwise, the Collection will be given the  
> DefaultCurrentUserConduit.
>
> I'm open to suggestions on this one though...

See above.
>
>>
>> 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}

}

> Thanks for the comments, very useful!
>
> -Travis

anytime!