bengbengbalabalabeng commented on issue #854:
URL: https://github.com/apache/fesod/issues/854#issuecomment-3991426940
Hi, @delei
Thanks for the review!
I completely understand the concern regarding "interface explosion" and the
simplicity of String-based tags. However, I still recommend sticking with the
Class/Interface approach for the following reasons:
1. Interface explosion
we can define static inner interfaces within their VOs or a dedicated
constant class. This keeps the project structure clean without creating
separate files for every group.
```java
@Data
public class SchoolWholeStatDataVO {
public interface SchoolGroup {}
public interface StudentGroup {}
@ExcelProperty(value = "School Name", groups = SchoolGroup.class)
private String schoolName;
@ExcelProperty(value = "Student Name", groups = StudentGroup.class)
private String studentName;
@ExcelProperty(value = "Update Time")
private Date updateTime;
private String className;
}
```
2. Hierarchical Grouping
Inclusion relationships can be handled automatically using Java inheritance
(Detail extends Base). Strings must be displayed and listed in all groups,
which is easy to miss and duplicate. When there are too many fields, it is more
likely to cause string group explosion.
Class/Interface
```java
@ExcelProperty(value = "No", groups = Base.class)
private String no;
@ExcelProperty(value = "Name", groups = Details.class)
private String name;
```
String
```java
@ExcelProperty(value = "No", groups = "base")
private String no;
@ExcelProperty(value = "Name", groups = {"base", "detail"})
private String name;
```
3. Type Safety
String-based tags are prone to misspellings and difficult to reconstruct.
Java Type-based avoid such problems at compile time.
So, I believe the robustness and functionality of the Java Type-based
approach offer greater advantages. It seems worthwhile to prioritize the
flexibility of inheritance over the simplicity of strings.
WDYT? Looking forward to your feedback.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
