This is great stuff. I added a link here:
http://wiki.eclipse.org/PDS_Use_Cases#Design_2
to this new page:
http://wiki.eclipse.org/Context_Editor_Design_Notes
and transcribed your email into the new page and tweaked a couple terms to
harmonize with latest Higgins conventions.
On Aug 24, 2011, at 5:33 PM, Iain MacNeill wrote:
> 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
