| 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
|
