Re: [higgins-dev] Context (aka card/membership/whateveryoucallit) editor

[Iain MacNeill <imacneill@xxxxxxxxx>]

Including the items discussed in our recent gathering, here is another breakdown of the flow/process during updates to context values.

It is broken up between Specific/Individual ("Connector") contexts, and "All About Me" aggregator contexts.

Note: This does not attempt to identify specific systems, but rather defines the flow of logic in general. Also, this does not go into detail regarding the connector synchronization process, but just references it.

Editing of Specific / individual ("Connector") context values:

• When simple scalar values are updated by the user:
• Begin Transaction
  
• the change is immediately pushed to persistent storage.
  
• No Errors: Commit Transaction - else Rollback and display error state
  
• For complex values, a modal dialog is presented to the user with all of the relevant context attributes displayed with their current values and 'Ok'/'Cancel' buttons.
• If the user either closes the tab or the browser, a browser level alert box will be presented requiring the user to confirm the loss of data.
• When the user clicks on the 'Ok' button:
  
• Begin Transaction
  
• changes are pushed to persistent storage. 
• No Errors: Commit Transaction - else Rollback and display error state
  

Editing of "All About Me" aggregator context (Addresses, Payment Cards, etc) values:

• When a simple scalar values are updated by the user:
• The user is presented with a dialog (TBD) which specifies (possibly: number of contexts to be changed, list of contexts to be changed) allowing them to confirm or cancel the update before it occurs.
• If user confirms change should occur:
  
• Begin Transaction:
  
• Call method to propagate changes across user's contexts (see below).
• If no errors are returned from call:
• Push "All About Me" context attribute value change to persistent storage.
• If update successful, then commit transaction.
  
• Else rollback transaction - display error state.
  
• Else Rollback Transaction - display error state
  
• For complex values, a modal dialog is presented to the user with all of the relevant context attributes displayed with their current values and 'Ok'/'Cancel' buttons.
• If the user either closes the tab or the browser, a browser level alert box will be presented requiring the user to confirm the loss of data.
• When the user clicks on the 'Ok' button:
• If something has actually been changed:
  
• Begin Transaction
  
• Call method to propagate changes across user's contexts (see below).
• If no errors are returned from call:
• Push "All About Me" context attribute value change to persistent storage.
• If update successful, then commit transaction.
  
• Else rollback transaction - display error state.
• Else rollback transaction - display error state.
  

Sequence to propagate a change across all user's contexts:

• Begin iterating the list of user's control template contexts:
  
• (At any point during the process, if an error occurs - processing will halt and the error returned.)
  
• If current searched context is a simple attribute and updated attribute is simple, then:
  
• If current searched context attribute/value matches original updated attribute/value, then
• Push updated attribute value to persistent storage.
  
• NO MATCH: proceed to the next.
  
• If current searched context is a complex attribute and updated attribute is complex, then:
  
• Compare all old attribute/values of the edited complex attribute against the current searched context, if all are equal then:
• Update the individual attribute values that have changed to match the new updated values.
• NO MATCH: proceed to the next.
  

• Proceed to the next retrieved context
  

On Fri, Aug 19, 2011 at 5:43 PM, Paul Trevithick <ptrevithick@xxxxxxxxx> wrote:

Iain,

I have a suggestion for how the context editor should work. It may well be what you and Valeska (and Tom and...) were already thinking. If fact, it may already be what we've coded in some cases! But let me describe it to you quickly and get your reaction...

• Editing modality
• There are no "Edit" vs. "non-Edit" modes (such as Apple AddressBook uses)
• If the user wishes to edit a simple attribute (e.g. gender) then they just edit that attribute's widget
• If the user wishes to edit a complex attribute (e.g. an address with street, postalCode, locality, etc. subcomponents, or a set of online-behavior:interest attributes (as we are doing today)) the UI pops up a modal dialog box ONLY for the purpose of editing this one complex-valued attribute (e.g. array of p:InterestTopics, v:Address, v:Name, etc.)
• The attribute and both its old and new values are retained for use in cross-context update (see below)
• If it is a simple attribute, this is one value
• If it is a complex attribute then all of the old values of the "sibling" attributes are retained. For example if the attribute was a v:adr (with an instance of v:Address as its value), and if the user changed the value of the v:postal-code attribute from 02467 to 01234 then any other "sibling" attributes/values would be retained. These sibling values might be the values of v:street, v:locality, v:region and v:country.
• Saving
• It saves data to persistent storage after the user has completed the edit operation as described in the simple and complex cases mentioned above
• Abandonment
• If the user is in the middle of editing a complex value and closes the tab of the portal / context editor it pops up the dialog box attached to this email below (copied from Google Docs)
• Cross-context update
• After any attribute of a p:Person in any context is edited, the editor searches EVERY other context of this user to update that same attribute of every p:Person found. 
• If it is a simple attribute and the "old" value of the attribute matches the old value of the attribute in the context the user was editing (see "modality" above) then replace the old value with the new value that the user entered 
• If it is a complex attribute that was edited then the same attribute (e.g. v:postal-code) will be updated if the following conditions are true:
• The old value of this v:postal-code matches the old value that was retained during the editing of the original context by the user
• The old values of the sibling attributes (v:street, v:locality, v:region and v:country) match the old values of these sibling attributes in the original context edited by the user 

A couple more thoughts about cross-context editing:

• I glossed over some complexities/recursion involved when the "sibling" attributes are themselves complex. Since we don't have any actual cases of this, this wrinkle is only theoretical.
• I didn't mention how cases of multi-valued attributes should be handled. This is a very real case we need to handle: the online-behavior:interest attribute usually has multiple instances of online-interest:InterestTopic as values. So the question is how to represent the "old" value(s) of interest. Should we only propagate the edit if ALL old values match? Well the answer is clearly no. We need only to remember whether we are adding or deleting a value. When we go to the other contexts we should (a) only add the value if it isn't already present (which in RDF isn't allowed anyway) AND if that value is explicitly mentioned as an allowed value by the template of the context (see new Attribute class and "allowedValue" attribute here [1]) and (b) only delete the value if it is present

I've written this all very quickly. This is deserving of a wiki page. In fact the cross-context attribute update should likely be broken out from the other (much simpler) points. I'll try to get to that next week.

Paul

[1] http://wiki.eclipse.org/Template_vocabulary