[Cosmo-dev] Topics Proposal

Matthew Eernisse mde at osafoundation.org
Wed Mar 28 11:15:07 PST 2007


Just some quick comments here. I'm going over e-mail, and making sure 
I've covered all the bases.

Bobby Rullo wrote:
>> From the perspective of (for example) the canvas rendering code, it's
>> pretty much the same, whether you're talking about the initial load of a
>> collection, navigating week-to-week, or making changes to an item. I
>> think it makes sense to treat them all the same way, but I'm open to
>> specific, concrete arguments about why we shouldn't.
>>
> 
> mde, this was a grueling decision to make. The upshot was this - if you 
> had to post a message to a topic everytime you loaded event (called 
> getEvent() ) you'd be posting lots and lots of topics.

Can you give me any real-world examples in the UI code where we actually 
load a single item at a time? I can't think of any. The only time 
information about a single item is coming back from the server is when 
the item has been edited (which of course publishes a message already).

Later on we may have examples of single items loading when we get into 
data synch and triaging, but even in those cases, there will be multiple 
UI widgets (canvas, detail form) that need to know the event has loaded. 
So it's the same deal -- something has changed about that item that 
multiple pieces of the UI need to know about.

Basically, it comes down to this -- any response from the server that 
triggers changes to multiple, independent pieces of the UI (canvas, 
detail form) should to publish a message to a topic.

Either that's built directly into the server layer, or the call will 
have to be wrapped in code that publishes a topic. Either way, you have 
a message published -- and it seems logically cleaner if all  the 
service methods behave consistently, right?

>> I'm not sure about Dashboard view, but the calendar canvas will need a
>> little more granularity to know how to render the result. It needs
>> metadata (e.g., the saveType prop currently used) along with the main
>> message so that it knows *what flavor* of update/removal success/failure
>> it has.
> 
> Perhaps. I don't doubt your expertise on this matter, but I'd like 
> messages to be as simple as possible, passing along the least amount of 
> info that is needed and with the service layer having as little smarts 
> as possible. Maybe some of this smarts can live outside the service 
> layer, with the widget maintaining that state itself.
> 
> Or maybe you're right, but I'm not convinced, so I'd rather go through 
> the pain of finding out I'm wrong. Learn a lot that way too :-)

A couple of problems with the widget maintaining state:

1. The metadata is nothing related to the widget. It's data about the 
actual request -- like (1) what type of save/remove operation (e.g., 
All, All Future) and (2) properties of the actual item (e.g., the start 
datetime of the event-item).

2. The operations are async, and cannot be assumed to return in any 
particular order.

When I implemented it, it seemed to make the most sense to package up 
all the necessary info about the operation, and pass the package along 
with with the request, so that when it came back, the canvas code could 
just look in that package for all the info it needs to render the change 
properly.

If we really don't like that approach, we could conceivably go back to 
some sort of external registry living in the canvas widget that links 
the requests to all the metadata about the request. That also sounds a 
bit like the event queue thinger that we've talked about from time to time.


Matthew



More information about the cosmo-dev mailing list