How to separate the content model for product cases and articles when they have different fields

How to separate the fields of products, cases, and articles to build separate content models? First, divide according to whether the front-end needs to filter and display fields: build a separate content model for those that require structured display; those that only need titles, content, and tags are categorized into the article model. That is, the product model puts parameters and specifications, the case model puts customer names and performance data, and the article model retains general fields. Mixing them in one model will make the list page, detail page, and document status become a set of conditional branches in the long run.

Which fields should be separated

Determine whether the field should be single-column, based on whether it participates in filtering, sorting, or external display. Fields involved in these actions should be able to store and query independently, and should not be retrieved from the text.

Content without additional fields can use the default model; once a type of content starts to show the need for filtering by a certain field, it should consider a new model rather than adding text marking.

Where does a mixed model get stuck.

The first problem with mixing is the list page. The product list needs to be sorted by specification, the article list needs to be sorted by publish time, and only the prefix of the title or tags can distinguish the same model, the filtering conditions become longer and longer. The second problem is the detail page template: the product needs to render the parameter table, the case needs to render the effectiveness figures, and the article is plain text, and the three layouts are squeezed into a single template, the conditional judgment will overrule the content itself. The third is the status process: the case often needs customer confirmation before it can be released, the article is published publicly, and the product needs to cooperate with the shelf and seasonal on and off-line, mixed together after the draft, to be published, and recycling station rules can't be distinguished by type.

Steps for decomposing the model into practice

The suggested order is: first list the field清单, then determine the model, and finally match the template. The first step is to list all the fields that need to be displayed on the front-end, indicating which need to be filtered and which need only be displayed; the second step is to build the content model according to this list, customize the fields once to ensure accuracy, keep the names consistent, and avoid writing synonymous fields multiple times; the third step is to match a list page and a detail page template for each model and clarify the ownership of categories and tags - categories express the structure of the column, tags express horizontal themes, and do not use tags to replace categories.

The sites that have already been launched do not need to be rebuilt all at once. You can first build models for the most painful category (usually products) separately, use batch import to fill in the existing content according to the new fields, verify that the list and details are normal before handling cases, and keep the articles as they are.

How to get the data for the list and details

After the model is disassembled, the data acquisition should also follow the model. The front-end can retrieve the document list and details by calling the API, where the parameters for the list, details, categories, and tags can be found in the interface documentation.The category tree and tag list are fetched once for caching, and then the article list is fetched by category to avoid repeated requests on each screen. The auxiliary capabilities are set according to the model: AI automatic tagging and TDK generation, and automatic title image matching during document creation are beneficial on models that require batch processing, such as content and case studies. For product models that require precise control of display, it is recommended to manually review the image matching and parameters.

The document status is managed in four levels: formal document, draft, pending release, and recycle bin: Cases are kept in draft before customer confirmation, use pending release for dates agreed upon, deleting a formal document means moving it to the recycle bin instead of physical deletion, and mistakenly deleted items can be restored here. The three types of content share the same set of status semantics, but the timing is determined individually, and the process will not be lost due to the breakdown of models.

Common questions

Will it be difficult to maintain if too many content models are built?The number of models should be equal to 'the real different display and filtering needs', usually between three and five. It is easiest to lose control when building a model for a one-time event, and it is more convenient to use a single page or article with tags for the event page.

Can I change the fields of a model that has already been built?Yes, but you need to handle the existing data: it is less costly to fill in the new fields, but you need to confirm whether the templates and API calls are still referencing the fields that are deleted or renamed.

Can the product and article share the same detail template?If the layout is similar, components can be reused, but the data acquisition and display fields should be separated. Otherwise, when adding a new filter, the two will be interconnected.

Will splitting the model affect search indexing?If the address rules do not change, it will not affect. After splitting, confirm that the pagination rules on the list page and the detail page URL are consistent, and the sitemap can be regenerated.