(Difference between pages)
No edit summary |
(Changed categories.) |
||
| Line 1: | Line 1: | ||
Integration of third party content into a wiki page can be achieved in various ways. It depends on several factors: | |||
== | == Embedding support by 3rd party == | ||
Does the software actively or via interfaces support embedding? Most web-based services nowadays do so, but some restrict functionality. | |||
''' | * '''Embedding widgets available:''' Does the 3rd party provide some widget code, which can be used for embedding? In the best case, the 3rd party already has some snippets ready, which do all the necessary embedding. This is the case e.g. for YouTube videos. In this case, we use the extension Widgets to create a wrapper, which includes the snippets mostly as they are provided. This is required for security reasons. Embeddings are very good for displaying complex content, such as video players, specialized graphics, dynamic diagrams, and so on, which require some sort of player. | ||
* '''API provided:''' If the 3rd party provides API access, an extension needs to be written, which calls the API and pulls the relevant data. This data then has to be transformed and be presented within the wiki. Depending on the complexity of the API, this can be a very simple task, but also a very challenging endeavor. API is very good for asking complex queries to the 3rd party database, and when the focus is mostly on the data retrieved (as opposed to the visualization). | |||
* '''SDK provided:''' Some 3rd parties provide software development kits that help creating complex applications on top of the software. Using SDKs is the best means when there is some complex interaction required between the wiki and the 3rd party, but typically the development of such connectors is very time-intense. | |||
== | == Authentication and access control == | ||
This is a limiting factor to which of the above ways can be used. | |||
* '''Client (browser) based authentication:''' The user has to be logged into the 3rd party system. On the pro side, the application has full control over authentication and access control. On the con side, this can be a nuisance in case there is no single login system in place, since the user will be prompted for logins. | |||
* '''Server side authentication:''' Communication between the 3rd party and the wiki is done on the server side. This means, the server has to take control over authentication. In this scenario, typically, communication takes place using a proxy user. On the pro side, this means the wiki user does not care about authentication. On the con side, however, per-user access control becomes hard to implement. It is possible, though. | |||
== Level of integration == | |||
[[ | |||
* '''Tease and redirect:''' In some scenarios, an integration wants to only get the attention of a user. For deep interaction, the user is redirected to the 3rd party software. This is the case, e.g., for embedding a ticket system number (which simply shows the ticket state, but for any interaction, the user has to follow the link to the ticket system). | |||
* '''Full read:''' In this scenario, the embedded content should be fully readable, such as with videos or graphics. There is no editing required. | |||
* '''Full interact:''' In this scenario, the full range of interaction should be supported. This is the case in BlueSpice with embedding Draw.io diagrams. | |||
There are several technical ways of embedding content. Mostly, we would try to work with widgets, as long as there is an embedding code or some ''iframe'' solution. | |||
[[Category:Customization]] | |||
Revision as of 18:14, 23 February 2023
Integration of third party content into a wiki page can be achieved in various ways. It depends on several factors:
Embedding support by 3rd party
Does the software actively or via interfaces support embedding? Most web-based services nowadays do so, but some restrict functionality.
- Embedding widgets available: Does the 3rd party provide some widget code, which can be used for embedding? In the best case, the 3rd party already has some snippets ready, which do all the necessary embedding. This is the case e.g. for YouTube videos. In this case, we use the extension Widgets to create a wrapper, which includes the snippets mostly as they are provided. This is required for security reasons. Embeddings are very good for displaying complex content, such as video players, specialized graphics, dynamic diagrams, and so on, which require some sort of player.
- API provided: If the 3rd party provides API access, an extension needs to be written, which calls the API and pulls the relevant data. This data then has to be transformed and be presented within the wiki. Depending on the complexity of the API, this can be a very simple task, but also a very challenging endeavor. API is very good for asking complex queries to the 3rd party database, and when the focus is mostly on the data retrieved (as opposed to the visualization).
- SDK provided: Some 3rd parties provide software development kits that help creating complex applications on top of the software. Using SDKs is the best means when there is some complex interaction required between the wiki and the 3rd party, but typically the development of such connectors is very time-intense.
Authentication and access control
This is a limiting factor to which of the above ways can be used.
- Client (browser) based authentication: The user has to be logged into the 3rd party system. On the pro side, the application has full control over authentication and access control. On the con side, this can be a nuisance in case there is no single login system in place, since the user will be prompted for logins.
- Server side authentication: Communication between the 3rd party and the wiki is done on the server side. This means, the server has to take control over authentication. In this scenario, typically, communication takes place using a proxy user. On the pro side, this means the wiki user does not care about authentication. On the con side, however, per-user access control becomes hard to implement. It is possible, though.
Level of integration
- Tease and redirect: In some scenarios, an integration wants to only get the attention of a user. For deep interaction, the user is redirected to the 3rd party software. This is the case, e.g., for embedding a ticket system number (which simply shows the ticket state, but for any interaction, the user has to follow the link to the ticket system).
- Full read: In this scenario, the embedded content should be fully readable, such as with videos or graphics. There is no editing required.
- Full interact: In this scenario, the full range of interaction should be supported. This is the case in BlueSpice with embedding Draw.io diagrams.
There are several technical ways of embedding content. Mostly, we would try to work with widgets, as long as there is an embedding code or some iframe solution.
Discussions