There is nothing wrong with using PageData or BlockData without views to stored structured data that is not necessarily meant for presentation purposes (or at least doesn't have its own view associated withit).
In fact you get benefits such as versioning, tranlsating, ab testing, etc. etc.
My preference is to use PageData as you can directly nest for hierarchical representations without needing 'folders' (as Blocks would need).
One major benefit of this is that as you're storing as IContent, you can optimise performance by using Find to query too
Hi,
My preference would be to use StandardContentBase, ContentBase or BasicContent depending on whether you want it to be versionable, localizable or whatever.
The Geta EpiCategories solution contains a solid example, with CategoryData inheriting StandardContentBase. It can hopefully provide you some inspiration and demonstrate how you can wire up the UI as well, although you can likely avoid the custom Dojo module.
If you need the information on a single page and do not need to be reusable on other pages you can look at creating a generic property list (IList) on the page, you can compare it to a content area for simple "only on this page"-blocks. Documentation: https://world.episerver.com/documentation/developer-guides/CMS/Content/Properties/generic-propertylist/
I'm trying to determine the best approach for storing "miscellaneous" data for a website. The use case is we'd like to store "Store Locations" which are not represented by pages, but they will all be shown on a page as a list. PageData or BlockData do not seem like good candidates because these records will not represent pages or blocks.
We do want content authors to be able to create/read/update/delete these store location records.
What is the best approach for creating this type of data structure, manage records via the CMS, and use the built in CMS APIs to read data?
Thanks!