Duplicate

Computer science has long discussed the issue of redundancy vs dependency and from time-to-time, it is a topic that arises in PageSeeder modeling.

The purpose of this article is to explain how modeling with links can address use cases that might otherwise require data duplication. However, the trade-off of using links to avoid redundancy can be the creation of dependencies.

Consider the following scenarios:

• Teacher and student views of a text book, where the teacher view has additional notes on a topic.
• Multiple parties simultaneously reviewing a document but wanting comments to be visible to only the other members of their party.
• Document fragments appearing in multiple parts of a publication but only requiring a single update.

Publish duplicate

(also known as a Filter duplicate)

This pattern is the safest and easiest way to manage duplicate content. Only a single copy of the data exists for editing and review. A developer processes this as input and duplicates the content in the output format.

The difference between a “publish duplicate” and a “filter duplicate” is that publish is “additive” (add teacher notes to the common text) and filter is “subtractive” (strip the teacher notes from the student text).

Shallow duplicate

This pattern is how the documents page copies a single file. With a shallow duplicate, any links that terminate outside the source document are copied to the duplicated document but the link destination is unchanged.

In other words, if docA links to docB, when docA is duplicated to create docC, it also links to docB.

Collection duplicate

This pattern replicates an entire collection of content and updates the path references to reflect the new location. It must be coded for each circumstance, but this tutorial provides some guidance for developers: Creating document collections.

This is similar to exporting a collection and then re-importing it to a different group.