[Cosmo-dev] Dashboard Plumbing Stuff

[Matthew Eernisse]

Responses/comments inline below.

Bobby Rullo wrote:
>     * New types of items need to be handled in Cosmo UI 

This would be a good opportunity to figure out how smart we want our 
Items to be. Right now the seemingly important function that decides 
what in an item has changed is languishing in legacy/cal_event.js. Are 
these just dumb data objects, or what? If the intelligence for that 
stuff isn't in the Item itself, where does it go?

>     * application level events (using dojo Topics) for notifications on 
> CUD (creates, updates and deletes) and other high level events (item 
> selected, date range changed, etc.

Might be helpful to take a look at what's already there and see which 
concepts or existing code can be evolved to do what we need. Here's a 
basic summary of what we have now:

Overview

Since you can pass a parameter as a 'payload' for a publish event, I've 
been using that object to inform the listening UI components of the 
specifics of the event, and letting them react as they see fit.

I think using these object payloads with a *well-documented* 
domain-specific language will allow us to keep the code slim and 
minimize the number of different topics/channels we need to create. 
(Right now the DSL is totally ad-hoc, and would obviously benefit from 
some actual design and proper doco.)

App-level events (js/cosmo/ui/event/handlers.js)

Keypresses publish to a topic called 'app.' My intention with this was 
to use the channel for events global to the app, such as keypresses or 
showing/hiding the modal dialog box. The call looks like this:

dojo.event.topic.publish('/app',
     { type: 'keyboardInput', appEvent: e });

The payload object in the current code has two properties:

1. type, the type of app event -- the current code simply uses the 
string 'keyboardInput', but eventually this value should be pulled from 
a defined set of constants.

2. appEvent, the actual DOM event -- allows responding code to react 
based on what key was pressed. We may decide that this is only a valid 
property when the app event is triggered by a DOM event.

Looking forward, if we were to use this topic to inform the app about 
showing the modal dialog, the call might look something like this:

dojo.event.topic.publish('/app',
     { type: 'modalDialog', toggleStatus: 'show' });

Hiding might be:

dojo.event.topic.publish('/app',
     { type: 'modalDialog', toggleStatus: 'hide' });

Calendar item events (js/cosmo/view/cal.js, js/cosmo/view/cal/canvas.js, 
and js/cosmo/ui/cal_form.js)

The code here publishes on a topic called '/calEvent'. I implemented 
this stuff on the fly for recurrence, so again, very ad-hoc. There's 
extensive use of topics, so there will be some substantial work to bring 
it in line with whatever 'designed' solution we come up with.

There are four properties I used for the payload object when publishing 
to this topic:

1. action, the type of action (e.g., 'eventsAddSuccess' or 
'saveFailed'). Could benefit from cataloging into a list of constants.

2. qualifier, some sort of qualifying info regarding the action -- e.g., 
'editExisting' (the 'save' operation failed, and it was an attempt to 
edit something already on the canvas) or 'onCanvas' (if false, the event 
was successfully saved, but its new start date means it's not on the 
viewable canvas anymore).

3. data, usuallly the event being removed/changed. (Naturally enough 
this gets fuzzy when dealing with recurrence.) In a couple of cases this 
contains two props, the original event and the expanded recurrence of 
events from the server.

4. opts, an object containing options for displaying the dialog of 
options for updating/removing (e.g., opts.recurrenceMod = true), options 
for a save/remove operation (e.g., opts.saveType = 'instanceAllFuture'), 
or the instance event clicked on when the actual edit applies to the 
master event in a recurrence (e.g., opts.originalEvent = ev). The info 
in this object is also often used in the canvas re-rendering process -- 
for example, to know which items in a recurrence to wipe, or where to 
put the item selection).

There is some conceptual overlap between the opts and the qualifier 
properties is some places -- it would be nice to consolidate them.

That's pretty much it.

If possible I'd like to continue the approach of thinking of topics as 
conceptual groupings of types of notifications that UI elements might 
want to react to, and put the relevant details about the actual 
notification in the payload object.

That way the interested pieces of the UI can inspect the contents of 
that object when it comes down the topic pipe and decide how (or if) 
they want to react.

I'd really like to avoid ending up with a massive number of topics -- 
i.e., a different topic for each kind of event possible, or similar 
approaches. It requires more overhead both computing-wise (to set up all 
the topic subscriptions) and cognitively (to follow all the possible 
avenues of communication).

> The goal is not to over-engineer here - quite the opposite. We are 
> trying to be as conservative as possible and only do what is necessary 
> for preview and to be a lean mean JavaScript machine.

Hear hear! And I want to make sure that whatever we come up with, the 
existing code gets refactored to reflect the new approach. Let's keep it 
simple and fast.

> Stay tuned (this week hopefully) for some proposals in these areas.

Looking forward to the proposals. The initial thoughts seem very promising.


Matthew