User blog comment:VuLinhAssassin/Testing - Ootsubo Yuka (Demo Seiyuu page)/@comment-26154973-20180102152436

Hey, I will comment on this, how I see it in relation to things we already have.
 * First, there is "data", each data piece (for a ship, equipment, seiyuu, CG artist, etc.) corresponds to a data module, so that the data is centralized and can be accessed from anywhere, data updates also force all clients to update (e.g., changing a ship data module can update corresponding ship page, stat tables, improvement tables, etc.).
 * Then, for a collection of data pieces (and its corresponding modules) of some kind (e.g., all ships, equipment, seiyuu, CG artists, etc.) there can be a collection module, so that collections are centralized and it is possible to iterate (with "iterator" concept, including possible sorting, filtering, grouping, etc.) over them, also from anywhere. Collection updates force all client listings to update (like equipment listing pages).
 * A "data piece" can have its page, corresponding collection can have a (categorized) set of pages. Those pages use some kind of layout template(s), which can use lower level templates or just invoke rendering code directly. Can say here that MVC layers, that is, data and client calls (also as C-handlers), rendering code and CSS, JS code and proxy modules/etc., are centralized and separated, to an extent, acyclic or cyclic if counting proxy modules/etc. . Number of invokes should be minimized, so we can't use aren't using portable infoboxes ( tag). That, and they will require some custom styling (compare with Template:ShipInfoKai, Template:ShipMetaKai or Template:EquipmentInfoKai). Some layout templates: Template:Ship, Template:Equipment.
 * So a seiyuu page can rely on existing data and collection modules and have some layout defined in Template:Seiyuu:

Additionally, Category:Ships voiced by Ootsubo Yuka/etc. is a trivial patch to Module:ShipCategoriesKai, same for CG artists.