[Cosmo-dev] Cosmo WebUI Service Layer

[Ted Leung]

On Mar 5, 2007, at 3:10 PM, Travis Vachon wrote:

>
> On Mar 5, 2007, at 1:30 PM, Bobby Rullo wrote:
>
>>> 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.

Error handling topic/notification?

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

Looking at this from a UI client API perspective.   If I have a  
collection of items, how often am I really going to know the UID?   
I'm much more likey to want to get some item that matches some set of  
property values.

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

+1 per my other message.

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

So the Conduit will update a field in items that it fetches?

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

Is there another proposal for the model, then?

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

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

So where do the conduit and ticketKey come from?  Forgive my  
ignorance on this one..

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

Listing the conduits sounds like useful functionality.

Ted