This is an area where using a programmable content infrastructure like Contentful really pays off. While Search and Saved Views continue to be useful throughout the entire lifetime of this content, it's often easier for content creators to navigate it using a more familiar method: the frontend itself. Indeed, that should get you started quickly and easily.Īs your content base grows, it's very natural for it to be surfaced and remixed in a variety of ways. One answer is to simply employ the Search and Saved Views features of our web app. So how can content creators browse and discover content easily? And when content is delivered across multiple channels, chances are each one navigates differently to the other. No matter which content geography is implemented, chances are navigating the CMS is going to be a different experience to navigating your client application. Entries know about their relationship with the tag but the tag has no idea which entries link to it. Listing all entries that have a tag is difficultīecause references are unidirectional, it's impossible to start from any given tag and discover all entries that have it. Again, this would traditionally be solved by running multiple queries or applying some sort of client-side caching. Meaning, entries which reference multiple tags cannot be retrieved with a single query.
Searching by reference only works on single reference fields. There are ways around that, of course, but they require either multiple queries or proxy content types. This is especially true when using multiple, closely related content types such as product variants. This fits the principle of curated content very well, which assumes a high degree of knowledge about what you're querying for, but it presents issues when you don't. The CDA allows querying for a single content type at a time. We'll call them "tags" in this article, but you could easily think of them as "sections" or "categories."ĭespite its ease of use, the old model presented drawbacks in some scenarios, which required careful architecting and modeling to solve. Tiny, specialized content types can be employed to further organize those topics and assemblies. They're therefore easy to reason about and easy to navigate, acting as containers and gateways to your topics. Assembly trees, shaped like the delivery channel(s) they're designed for, can then reference your topics and thus indirectly organize them in trees.Īssemblies, by matching the geography of your delivery channel(s), follow a structure which is familiar to your content creators. A graph of topics can take any shape at all, arising naturally from the very structure of the information managed by your business. Splitting the content model into Topics and Assemblies helps. This fundamental difference can be tricky to reconcile, especially in projects migrating from legacy to modern CMS. As such, fragments can cross-link to one another to form a complex graph, which rarely looks like a simple tree. Because fragments are reusable, they can surface in more than one place, across multiple channels (such as websites, native apps, etc). Trees apply well to page-centric approaches, but not when it comes to content organized in structured, granular content fragments. So, legacy Content Management Systems (CMSes) evolved to provide neat tree structures as the default geography. The historical way of managing content for the Web had created an expectation that all content belongs somewhere on the site map.
0 kommentar(er)
