Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
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}}
Contents
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
- She navigates in web client to a place where a gallery of available templates is displayed
- She clicks on the "Google Ads" card-shaped template
- She sees a new Google Ads card in her list of cards
Assumptions
- Alice is already logged in to her PDS web client
- The PDS includes a card gallery
- PDS gallery is pre-configured with a set of template contexts and one of these is the Google Ads template.
Design
Data model:
- Template vocabulary shows an example template--this example is the Google Ads template
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?
- A: See Template vocabulary#UML_Overview--the tempalte has a proxy:connectiontype attribute whose value should be copied to the Proxy.
Logic:
- 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.
- Client instantiates the participant context based on the Participant prototype in the template
- 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
- 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
- She navigates to a place that shows her list of cards
- She clicks on a card (e.g. Google Ads") to select it
- The card displays a set of attributes
- Alice edits the value of some attribute
Assumptions
- Alice logs into web client