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 <[email protected]>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
>
>
_______________________________________________
higgins-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/higgins-dev
