[Cosmo-dev] Cosmo WebUI Service Layer

[Travis Vachon]

On Mar 5, 2007, at 1:30 PM, Bobby Rullo wrote:

> Overall seems pretty good. Here are my comments:
>
>> "Therefore, there should be a single Conduit instance for  
>> interacting with a user's "Owned" collections, and a single  
>> Conduit instance for each ticket in a user's subcriptions."
>
>
> I think it's more accurate to say "...a single Conduit for each of  
> a user's subscriptions" - which would probably be the same as one  
> for each ticket.

Agreed
>> Example: retry
>> There will, in the future...
>
> 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.
>> Please see the dojo.Deferred API reference for more information  
>> about Deferreds.
>
> Doesn't really tell you that much unfortunately...
>
True. I think I'll see if I can't submit some documentation to them.  
Until then, I'll put something up on our wiki with better information  
about how to use these. If it helps, they're very similar to Python's  
Twisted library deferreds, so reading those docs (http:// 
twistedmatrix.com/projects/core/documentation/howto/defer.html) might  
be useful.
>>  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.
>
>> 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:

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.


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

>
> 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}
> 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])?

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

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

Thanks for the comments, very useful!

-Travis

>
> Bobby