Bureaucrats, confirmed, Administrators
4,558
edits
Changes
Created page with "thumb|Authors|left|link=thumb|Audience|right|link= A decoupled architecture is one that separates the publishing from the c..."
[[File:System-users.svg|thumb|Authors|left|link=]][[File:System-users.svg|thumb|Audience|right|link=]]
A decoupled architecture is one that separates the publishing from the content authoring. This contrasts with "coupled" systems where content authoring is tightly coupled with the delivery of the content. In early Content Management Systems, it was a feature that you could edit right in the delivery mechanism. Or, to put it simply, if you were logged in to the website as an editor, you could edit the page content "in place". This is still a great feature. However, delivery mechanisms have become more complex and multi-platform. At the same time, content is very often integrated from multiple sources. In these circumstances, it may make sense to de-couple the application architecture.
== Example ==
One very interesting example is with the MediaWiki system. The user interface is very difficult to "skin" or customize in a way that is desirable and blends with your company's brand. Also, many of the features of the system that are great for authors do not mix well with the delivery of the content in another system. However, since MediaWiki has a strong API, it's easy to grab and reuse content from a "backend" wiki system and present it in a totally un-related front-end website. For example, we use the [[Wiki report]] page as a "backend" authoring environment for delivery to the "frontend" company website: https://equality-tech.com/content/wiki-report-now-available
[[Category:Architecture]]
A decoupled architecture is one that separates the publishing from the content authoring. This contrasts with "coupled" systems where content authoring is tightly coupled with the delivery of the content. In early Content Management Systems, it was a feature that you could edit right in the delivery mechanism. Or, to put it simply, if you were logged in to the website as an editor, you could edit the page content "in place". This is still a great feature. However, delivery mechanisms have become more complex and multi-platform. At the same time, content is very often integrated from multiple sources. In these circumstances, it may make sense to de-couple the application architecture.
== Example ==
One very interesting example is with the MediaWiki system. The user interface is very difficult to "skin" or customize in a way that is desirable and blends with your company's brand. Also, many of the features of the system that are great for authors do not mix well with the delivery of the content in another system. However, since MediaWiki has a strong API, it's easy to grab and reuse content from a "backend" wiki system and present it in a totally un-related front-end website. For example, we use the [[Wiki report]] page as a "backend" authoring environment for delivery to the "frontend" company website: https://equality-tech.com/content/wiki-report-now-available
[[Category:Architecture]]