Does Smart Doc support the function of setting tags for a specific interface?

[miaoweibiao]

Summary(关于这个pr的描述)

Tag the interfaces, and then you can filter the interfaces based on the tags.
给接口打标签，然后可以根据标签筛选接口

Basic example(pr的用例)

If the proposal involves a new or changed API, include a basic code example. Omit this section if it's not applicable.

Motivation(提出这个pr目的)

Different iterations involve different interfaces, and currently, the server side verbally informs the front-end or client which interfaces are involved in this version, and then they have to search for them one by one.
If there were a tagging feature, the front-end could quickly find the interfaces involved in this iteration.

不同的迭代会涉及到不同的接口，现在都是服务端在口头告诉前端或者客户端，这个版本涉及到哪些接口，然后再一个个找
要是有个标签功能，前端就可以快速找到本次迭代涉及到的接口了

[shalousun]

Could you describe your usage scenario, such as whatCould you describe your usage scenario, such as what with Smart-Doc and how such as what tools are used in conjunction with Smart-Doc and how to search?
可以描述下你使用场景，比如smart-doc是和什么工具结合使用的，怎么搜索的

[miaoweibiao]

Can you describe your usage scenario, such as what tools smart-doc is integrated with and how the search works?

1. Currently, it is not integrated with any tools—just standalone smart-doc, as it is relatively lightweight.
2. For example, in a typical scenario:
   (1) For a particular requirement, the server and client involve the addition and modification of several interfaces, such as:
   xxxController1.xxx1, xxxController1.xxx2, xxxController2.xxx1
   (2) In the current setup, the server needs to manually document these URIs one by one and inform the client about the modified interfaces.
   (3) Suppose the server could tag certain interfaces in the configuration file, assigning them a specific label (e.g., xxx). Then, the server only needs to tell the client that the interfaces related to this requirement are under the tag xxx. The client can simply search by the tag xxx to see all relevant interfaces.
3. Currently, a feasible implementation I can think of is adding an option in the configuration file, combined with packageFilters, to generate different API documentation pages for different tags. For example:
   a. Add a tag option in the configuration, like:

   "tag": {  
     "tag1": { "packageFilters": "xxxController.xxx, ..." }  
   }  

   b. Based on the number of tag keys (n), generate n + 1 documentation files (one being the full documentation).
   c. On the page, provide a way to select different documentation views based on the tag key.
   However, this approach does not support filtering by multiple tags simultaneously. Just a rough idea for reference.

[shalousun]

@miaoweibiao Maybe we should adopt a version-based iteration approach later, similar to code tags. The framework already supports the @Version tag at the method level—it’s just not currently displayed in the UI. Other solutions might deviate too much from standardized practices.

As an open-source tool, introducing excessive configurations could also drift away from smart-doc's core philosophy.

[miaoweibiao]

@miaoweibiao Maybe we should adopt version-based iteration later, similar to code tags. The framework already supports the @Version tag at the method level—it's just not currently displayed. Other approaches might deviate too much from standardized practices. As an open-source tool, excessive configurations could also drift away from smart-doc's philosophy.

If we add tags at the method level, we'd have to remove them one by one after completing a requirement, which is a bit cumbersome. If it's done in the configuration file, we can simply delete them there. But ultimately, this should be implemented based on your actual needs.