GitHub user bengbengbalabalabeng closed a discussion: [Discussion & Question]
Confusion about the use case where `clazz` != `headClass` in
`ClassUtils#declaredExcelContentProperty`
Parameter Description:
- `clazz`：actual data type
- `headClass`：configuration data type
In the `ClassUtils#declaredExcelContentProperty` method, there exists logic
that allows the `headClass` and `clazz` to be inconsistent, and the
`ExcelContentProperty` object defined by `clazz` will override the one from
`headClass`.
To understand the applicable scenarios of this design, I tried the following
two patterns that trigger `clazz != headClass`, but found that neither produced
the expected results in actual execution.
**1. Parent/Child Class Pattern**
Model Definition:
```java
@Data
public class ExcelSuperModel {
@ExcelProperty(value = "Super NAME")
private String name;
}
@EqualsAndHashCode(callSuper = true)
@Data
public class ExcelModel extends ExcelSuperModel {
// Mode 1: Expected to override the parent class's field header name with
the same name
@ExcelProperty(value = "Sub NAME")
// Mode 2: Expected to override the default behavior of parent class fields
with the same name, set to ignore
// @ExcelIgnore
private String name;
}
```
Run Test
```java
// Now headClass = ExcelSuperModel.class, clazz = ExcelModel.class
FesodSheet.write(output, ExcelSuperModel.class)
.sheet()
// datas() ruturn List<ExcelModel>
.doWrite(datas());
```
Result: The `@ExcelProperty` or `@ExcelIgnore` setting in the subclass is
invalid, and the header in the Excel file remains "Super NAME".
The logic of `headNameList` and `ignore` has already been processed when the
`ExcelHeadProperty#initColumnProperties` method calls
`ClassUtils#declaredFields`. Here, only `ExcelSuperModel` ( = `headClass`) is
always processed, without considering the annotations of `ExcelModel` ( =
`clazz`) at all.
> Note: In the `ClassUtils#doDeclaredFieldContentMap` method, the
> implementation for retrieving all fields also has an overriding issue when
> handling fields with the same name in parent and child classes. For details,
> refer to the fix in [PR 427](https://github.com/apache/fesod/pull/427).
**2. Interface/Implementation Class Pattern**
Model Definition:
```java
public interface ExcelSuperInterface {
void setName(String name);
String getName();
}
@Data
public class ExcelModel implements ExcelSuperInterface {
@ExcelProperty(value = "Impl NAME")
private String name;
@ExcelProperty(value = "ADDRESS")
private String address;
}
```
Run Test
```java
// Now headClass = ExcelSuperInterface.class, clazz = ExcelModel.class
FesodSheet.write(output, ExcelSuperInterface.class)
.sheet()
// datas() return List<ExcelModel>
.doWrite(datas());
```
Result: `@ExcelProperty` setting is completely ineffective, and the exported
Excel does not contain headers at all.
**Question**
Both of the above will trigger the logic of `clazz != headClass`, but the
results do not meet expectations.
Therefore, what I want to explore is:
1. If the current architecture requires that the `headClass` must be strictly
consistent with the `clazz`, is the merge/overwrite logic in
`ClassUtils#doGetExcelContentProperty` for `clazz != headClass` redundant?
2. Are there any specific business scenarios I haven't covered that are
specifically designed to leverage this `clazz != headClass` logic?
GitHub link: https://github.com/apache/fesod/discussions/919
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
