[Cosmo-dev] Cosmo WebUI Service Layer

[Bobby Rullo]

On Mar 5, 2007, at 3:31 PM, Ted Leung wrote:

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

I don't think it would work in this case, Ted. The topic would fire,  
but the original caller would already get a callback saying it failed.

Now, if we decided to make EVERYTHING async and totally break apis  
that we have we could do this. You would have "TryToSave" topic which  
could get picked up by the service layer, and it could try and save,  
and post a topic if it failed, and something else could pick up that,  
log the user in, post the "TryToSave" message again....

But I don't think we are going this route. It felt too heavy and  
would require (too) much re-writing of existing code.

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

Good point, maybe "getItem(uid)" is not such a useful thing on a  
colleciton.
>
>>>
>>>> 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 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?
>

What do you mean? If you mean that a conduit will stick it self in  
any item it fecthes, than yes.

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

Well, the service layer and the model are seeming to become intwined.