The data structures used to create workflows can be a bit cumbersome, especially for projects that wrap friend-oauth2 or provide convenience functionality on top of friend-oauth2. I have experimented with some fully backwards-compatible mechanisms for lessening this developer/user burden. The use of records and a couple of functions that convert a flat/simple config record to the data structures needed by friend-oauth2 has been an especially clean (and fully optional) approach.
This is probably just going to be a documentation effort more than anything, perhaps showing a new set of examples that use such an approach ...
Tasks:
[x] Add links to the official service documentation for all the services in the examples
[x] Identify all the fields needed for all the the services in the examples
[x] Google
[x] Github
[x] App.net
[x] Facebook
[x] Define record that can be used for all supported examples - #76
[x] Define utility functions for creating a client and uri configs - #77
[x] Update the workflow function so that it can take both the record and the map configurations - #78
[x] Document both approaches (separately) in the "Configuration" section of the docs
oubiwann
commented
7 years ago
The data structures used to create workflows can be a bit cumbersome, especially for projects that wrap friend-oauth2 or provide convenience functionality on top of friend-oauth2. I have experimented with some fully backwards-compatible mechanisms for lessening this developer/user burden. The use of records and a couple of functions that convert a flat/simple config record to the data structures needed by friend-oauth2 has been an especially clean (and fully optional) approach.
This is probably just going to be a documentation effort more than anything, perhaps showing a new set of examples that use such an approach ...
Tasks:
workflowfunction so that it can take both the record and the map configurations - #78Part of release #64