Skip to main content
Jump to: navigation, search

Difference between revisions of "PDS Use Cases"

(Create a connection to a site from a card in gallery)
Line 4: Line 4:
  
 
Note: Cards represent a relationship between the user and an external site or business. The relationship includes a bi-directional data connection that shares and synchronizes a set of attributes between the site and the user's PDS. This set is a site-specific subset of the user's attributes.
 
Note: Cards represent a relationship between the user and an external site or business. The relationship includes a bi-directional data connection that shares and synchronizes a set of attributes between the site and the user's PDS. This set is a site-specific subset of the user's attributes.
 +
 +
The card gallery contains a set of pre-defined card templates (all of class ConnectorTemplate, and all of whose Definer Connector are of calss WebsiteFacade). When the user clicks on one of these templates, it creates a pair of connection contexts as described here (). The WebsiteFacade Definer ContextPrototype instance has an an associated app-data:JavaScript entity that contains a JavaScript that, when loaded into the HBX runtime environment, acts as a facade over a plain-old website. The facade uses HTML scraping to pull attributes from the site, and uses form filling to push attributes to the site, thereby synchronizing the contents of the WebsiteFacade>Definer>ContextPrototype with the site.
  
 
===Story===
 
===Story===

Revision as of 13:22, 27 August 2011

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Create a connection to a site from a card in gallery

Note: Cards represent a relationship between the user and an external site or business. The relationship includes a bi-directional data connection that shares and synchronizes a set of attributes between the site and the user's PDS. This set is a site-specific subset of the user's attributes.

The card gallery contains a set of pre-defined card templates (all of class ConnectorTemplate, and all of whose Definer Connector are of calss WebsiteFacade). When the user clicks on one of these templates, it creates a pair of connection contexts as described here (). The WebsiteFacade Definer ContextPrototype instance has an an associated app-data:JavaScript entity that contains a JavaScript that, when loaded into the HBX runtime environment, acts as a facade over a plain-old website. The facade uses HTML scraping to pull attributes from the site, and uses form filling to push attributes to the site, thereby synchronizing the contents of the WebsiteFacade>Definer>ContextPrototype with the site.

Story

  1. She navigates in web client to a place where a gallery of available templates is displayed
  2. She clicks on the "Google Ads" card-shaped template
  3. She sees a new Google Ads card in her list of cards

Assumptions

  1. Alice is already logged in to her PDS web client
  2. The PDS includes a card gallery
  3. PDS gallery is pre-configured with a set of template contexts and one of these is the Google Ads template.

Design

Data model:

Issues:

  • Q: How does the PDS code know by inspection of the card gallery whether the PDS user is the definer/creator of the template? In other words how does it know which role (definer vs. participant) it should play?
    • A: If the card is in the gallery at all, we will assume it was defined by an external (non-user) definer. We'll put user-defined templates somewhere else.
  • Q: how is the connectionType for the Proxy determined from the template?

Logic:

  1. Flow stars in the cline (aka portal). User opens the card gallery. User selects card to add. For consistency we very roughly follow the context building flow here Person-site Relationship Management.
  2. Client instantiates the participant context based on the Participant prototype in the template
  3. Client instantiates the definer context based on the Definer prototype in the template. It also adds an h:correlation link from the newly minted p:Person in the Definer context to the p:Person in the Participant context
  4. Client adds the reciprocal h:correlation link

Create a connection with a site that natively supports (some) connection protocol

Story

User goes to a site that allows a PDS-to-site connection. (We're being vague here about the protocol because we assume it can entirely be done using the hot-off-the-presses OpenID Connect protocol, but we're not yet sure).

Design

Edit simple or complex attribute of a card

Story

  1. She navigates to a place that shows her list of cards
  2. She clicks on a card (e.g. Google Ads") to select it
  3. The card displays a set of attributes
  4. Alice edits the value of some attribute

Assumptions

  1. Alice logs into web client

Design

Back to the top