[Cosmo-dev] Item Deltas

[Matthew Eernisse]

Comments below ...

Bobby Rullo wrote:
> Things start off like they always have:
> * The user edits a bunch of stuff in the form fields.
> * The user clicks "save"
> * Validation happens, passes.
> * String values in form are converted to the proper types (Dates, 
> RecurrenceRules, etcetera)

This came up before, but just a reminder that edits can happen by the 
user manipulating the lozenge too. Right now it's just changing the 
start/end, but we will be implementing edit-in-place for the title to at 
some point.

> Here's where the new stuff happens:
> * Instead of cloning the original item setting the new values on the 
> clone, you instantiate a "Delta" object

Actually the way it works now is the reverse -- the UI makes a backup 
snapshot of the object, and makes its changes to the original. Don't 
know if that's just academic, or actually relevant, but seemed to be 
worth mentioning.

> * Now the delta object contains only changes. Now you want to know which 
> buttons to show if it's a recurring event (i.e "only this event", "all 
> events", "this and future") so you can call the following methods:
> 
>     var showAllEventsButton = delta.isApplicaibleToMaster() //for "all 
> events"
>     var showJustThisOneButton =  
> delta.isApplicableToJustThisOneOccurence() //an obviously too-long name 
> to illustrate a point
>     var showThisAndFutureButton = delta.isApplicableToThisAndFuture()

That sounds good -- and actually that is really not very different at 
all from what occurs now.

The hasChanged method in cal_event.js returns an object that has the 
list of changes (the delta) -- but in addition it includes both the 
original and updated values for the changed properties. That way I can 
see, for example, if the user is adding recurrence to an event that 
doesn't have it, or vice-versa.

And of course instead of being nicely encapsulated in method calls, the 
various tests are all sitting right out in the gateway function that 
invokes the dialog box before a save or remove. There's also that ugly 
inline function isOutOfIntervalRange that tells us whether or not the 
edit has to be limited to just the single occurrence.

It would be nice to get that stuff cleaned up.

> * Now the dialog box gets displayed and the user chooses let's say "All 
> Events". Now you apply the delta appropriately:
> 
>     delta.applyDeltaToMaster();
> 
> * or maybe they choose "only this event"
> 
>     delta.applyToOccurence()
> 
> * Now the original event has all the changes applied to it. Now you can 
> just save the master event:
> 
>     service.saveItem(originalItemOrOccurence.getMaster())

I think it would be excellent if we could take a lot of that ugly inline 
conditional logic and package it up with a meaningful name attached to it.

The only thing I think might be missing is the fact that the original 
purpose of making a pre-edit snapshot of the event was so that I could 
restore the lozenge and detail view state if an edit fails.

We already have logic that tells the detail view or lozenge how to 
update themselves based on the data in an event. If we make a backup 
copy before mucking with the item, it's super-easy to put things back 
the way they were when an edit goes south.

Thanks for the hard work on this -- it's looking good. :)


Matthew