[Cosmo-dev] Topics Proposal

[Bobby Rullo]

On Mar 5, 2007, at 5:24 PM, Matthew Eernisse wrote:

> Resending because it got trapped in moderation purgatory ...
>
> I'm copy-pasting stuff here from the wiki page to avoid cluttering the
> page with chitchat. It'll also make it clearer what points I'm talking
> about.
>
> One of my biggest questions was this -- what exactly defines "high- 
> level
> events"? Does that mean that the use of topics should be reserved  
> solely
> for these? Or would there be other places in the UI code potentially
> using topics in a different way?
>

Yeah for sure! Use topics for other stuff too, but this was just  
addressing high level events, meaning semantic level meaning things  
(Item was updated) as opposed to low-level things (div was clicked)

> Bobby Rullo wrote:
>> Hi all. Here is my first attempt at a proposal for a notification  
>> framework for the CosmoUI
>> http://wiki.osafoundation.org/Projects/HighLevelCosmoUIEventsProposal
>
>> Well Defined
>> The messages that are sent via topics will be well-defined and  
>> documented, so that future elements can take advantage
>> of them. Ad-hoc topics or messages should not be created,
>> and existing ones should be either formalized or removed.
>
> Agreed. Well-defined and documented is good.
>
> However, I would add that I'm not delusional enough to believe that we
> can actually *pre-define* every topic or message -- there will be  
> things
> that shake out during implementation that will necessitate our making
> changes to our plan. In that case we'll have to formalize the  
> changes as
> we go.
>

Of course.

> I also have some questions about how granular we want to be, for
> example, in attempting to pre-define what's in a package of data sent
> with all published messages of a particular type. When I was
> implementing recurrence, there were many occasions where I was totally
> unable to anticipate all the things up-front that the canvas might  
> need
> to know to re-render after a particular kind of update.
>
>
Well, I'm sure they'll be things that need to change, hard to get  
things right the first time. But now that you've gone and implemented  
a calendar canvas, we should have a pretty good idea of where to look  
for what stuff something needs to know to update itself.
>

> Sometimes we will need to publish messages to pieces of the UI *in
> preparation for* a service call, so the UI code can do things like  
> show
> a 'processing' message or make a backup copy of the data in the  
> item for
> the update-failure rollback.
>

Aw, aitch ee double hockey sticks. You're right. That was my original  
proposal, but travis convinced me that it was too heavyweight. But I  
forgot about this stuff.

What say you tvachon?

> The coordination between the minical, the go-to date box, and
> week-to-week navigation arrows is a good example of this.
>
right, right.

>> Whodunnit? It's preferable that the publishing of a particular  
>> message happens at one place in the code, so there is no ambiguity  
>> as to "who" should do the calling. For some messages, this is pretty
>> clear: since all saving of items happens at the service layer,
>> the service layer should be publishing topics.
>
> I may be totally missing something here, but I can't see how limiting
> the publish call to the service layer resolves the question of who is
> doing the calling. It seems like you have two choices -- (1) disparate
> UI elements publishing directly to a topic, or (2) disparate UI  
> elements
> each calling methods in the service layer that will then publish to  
> a topic.
>
> Both approaches will require building in something specific to  
> indicate
> where (i.e., from which piece of the UI) the chain of execution  
> started.
>

It's not resolving who does the calling, just who does the  
publishing. If the publishing for a particular thing happens at one  
place, there's no ambiguity about who should publish it, or danger of  
it being published twice. What you said (2) is what I was proposing.

> A good example of this is the fix for bug 7678 -- the minical needs to
> know if the call to change the view date-range originated with itself,

yeah. that's what the rid's are for.

> or somewhere else. Based on that, it knows whether to re-render
> completely, or just change the selection location.
>
> One way to deal with this might be a formalized piece of data in
> published messages such as messageOriginator or some such.
>

see above...

> It also seems like deciding that "publishing of a particular message
> should only happen in one place in the code" might be giving up a  
> little
> too much of the advantage of decentralization that topics give us.
>

I don't think so...could you elaborate a little?

>> Loading an item(s) is not an Event
>> Loading items will not cause a message to be published. Travis and  
>> I agonized over this, but for performance reasons and
>> philosophical reasons we don't think this is a good idea. The
>> rule for model related messages is that messages only get
>> published when something changes - the fact that something
>> loaded is not a change.
>
>
>
> 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.

So it might kind of stink that loading an event doesn't post on a  
topic, but you just code with that in mind, which is why I explicitly  
stated it. The minical doesn't need to know every event that loaded,  
just that the view range changed. Tvachon argued that it needs to  
have event info to populate the "bat droppings" once we have that  
functionality. But I retorted that it's actually not the same  
information, and it's for a large (3 months) date range, and it could  
be a different service method.

>> type = "updated" <-- either "updated", "created" or "deleted"
>
> 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 :-)

>
> Also, when an error occurs, the UI work doesn't stop with  
> displaying the
> error message -- there is rollback rendering to do. So the message  
> type
> either needs to encompass a notion of success/failure (as with the
> saveAction property (with values like removeSuccess or saveFailed) in
> the current code), or we'll want a success/failure flag to indicate  
> the
> final status of the operation.

See the end bit about backwards compat. for this. That code can exist  
pretty much as is.

>
>> item = <<object>> <-- the item in its updated form (null if deletion)
>
> In cases with recurrence, updating the UI correctly requires more than
> the currently selected (or even the currently updated) item -- an
> example of this is the instanceEvent and originalEvent properties  
> being
> passed now in the data object published through topics.

Same thing about going through pain, simplicity, etc.

>
>>  Retrofitting with Existing Code, Widgets
>
>
> That's all I've got for now. Very, very good work with this stuff,
> y'all. I'm really looking forward to moving these ideas into the  
> codebase.
>

Thanks Matthew!

Note that this proposal is fairly detailed, but stuff always pops up  
during implementation, like you said. I'd rather start overly- 
lightweight about certain things (the ones noted above) and add the  
minimal amount of code to make it work than the other way around.  
Might not be possible to get as simple as it is in one's head, but  
it's an ideal to work towards.

No one knows this stuff better than you obviously since you wrote it  
all, which is why I probably sound a little naive with respect to  
some of it. But hopefully that will change after I start working with  
all this stuff.

Bobby