I noticed the usage example you provided. It seems that the existing ReadListener is sufficient。

BTW, the new utility class must be called by the user themselves, which may not be a good experience.

I noticed the usage example you provided. It seems that the existing ReadListener is sufficient。

BTW, the new utility class must be called by the user themselves, which may not be a good experience.

Hi@delei! Thanks for the feedback! 👋

I appreciate you taking the time to review the PR. Let me address your concerns:

Regarding ReadListener sufficiency

You're absolutely right thatReadListener can handle validation logic. However, there are several advantages to a standardized approach:

Current approach with ReadListener:

publicclassProjectDataListenerextendsAnalysisEventListener<ProjectData> {@Overridepublicvoidinvoke(ProjectDatadata,AnalysisContextcontext) {// Manual validation logic for each fieldif (data.getProjectName() ==null ||data.getProjectName().trim().isEmpty()) {// Handle error - but how? Where to collect errors?        }if (data.getBudget() ==null) {// More manual validation...        }// Repeat for every required field, in every listener, for every project    }}

With ExcelValidationUtils:

@DatapublicclassProjectData {@ExcelProperty("Project Name")@ExcelRequired(message ="Project name is required")privateStringprojectName;@ExcelProperty("Budget")@ExcelRequired(message ="Budget cannot be empty")privateBigDecimalbudget;}// Simple, reusable, consistent validationList<ValidationResult>results =ExcelValidationUtils.validateRequiredBatch(dataList);

Benefits of the standardized approach:

1. Consistency - Same validation logic across all projects
2. Reusability - Write once, use everywhere
3. Maintainability - Centralized validation logic
4. Error handling - Standardized error collection and reporting
5. Testing - Easy to unit test validation rules
6. Documentation - Self-documenting through annotations

Regarding user experience

I understand the concern about manual calls, but consider:

Current reality:

• Users already write custom ReadListener implementations
• Each listener contains repetitive validation code
• Error handling is inconsistent across projects
• No standard way to collect and report validation errors

With this utility:

• One-time setup with annotations
• Consistent error reporting format
• Reusable across multiple Excel import scenarios
• Foundation for future enhancements (auto-validation integration)

Future vision

This is actuallyPhase 1 of a larger validation system. Future phases could include:

• Automatic validation integration (no manual calls needed)
• Write-time validation (dropdown, numeric, date constraints)
• Seamless integration with existing FastExcel workflows

Real-world example

Consider a company with 10 different Excel import features.

Currently:

• 10 different ReadListener implementations
• 10 different validation approaches
• Inconsistent error messages
• Difficult to maintain and test

With ExcelValidationUtils:

• Consistent validation across all imports
• Standardized error reporting
• Easy to add new validation rules
• Much easier to maintain and test

Question for you

Have you worked on projects with multiple Excel import features? How do you currently handle validation consistency across different imports?

I'd love to hear your thoughts on how we could make the user experience even better while maintaining the benefits of standardization!

Note: This utility is designed to complement, not replace, ReadListener. Developers can still use custom listeners for complex business logic while leveraging standardized validation for common scenarios.

I need to re-emphasize: anyone (including project maintainers, committers) who wants to add a new feature needs to discuss it in issue or disscusion, and only then can we confirm who to assign it to, and the subsequent release schedule.
We welcome any contributors, but will not merge features thathave not been discussed and confirmed without discussion.

It works even better in combination with hibernate-validator

FYI: We're not opposed to the use of AI, but would like to keep things as simple as possible when communicating

Verification features are indeed what we need. The community is willing to listen to more suggestions and also needs to understand the specific implementation ideas.

I need to re-emphasize: anyone (including project maintainers, committers) who wants to add a new feature needs to discuss it in issue or disscusion, and only then can we confirm who to assign it to, and the subsequent release schedule. We welcome any contributors, but will not merge features thathave not been discussed and confirmed without discussion.

Got it, thanks for clarifying the process.

I actually created a discussion thread about the broader validation features right after submitting this PR. This current PR is just a small utility class - nothing fancy, just basic required field validation.

Should I wait for the discussion to conclude before this gets reviewed, or can this small utility be evaluated on its own? It's pretty minimal - just one class and one annotation.

Also, I see@wangmiscoding has PR#282 on similar stuff. Should we coordinate somehow?

Happy to follow whatever process works best for the project.

我需要再次强调：任何想要添加新功能的人（包括项目维护者、提交者）都需要在 issue 或 disscusion 中进行讨论，只有这样我们才能确认将其分配给谁，以及后续的发布时间表。我们欢迎任何贡献者，但不会合并未经讨论而未经讨论和确认的功能。

Got it, thanks for clarifying the process.

I actually created a discussion thread about the broader validation features right after submitting this PR. This current PR is just a small utility class - nothing fancy, just basic required field validation.

Should I wait for the discussion to conclude before this gets reviewed, or can this small utility be evaluated on its own? It's pretty minimal - just one class and one annotation.

Also, I see@wangmiscoding has PR#282 on similar stuff. Should we coordinate somehow?

Happy to follow whatever process works best for the project.

Probably won't be able to merge in 1.3.0 for a while (since we were planning to release it in the near future)
We'll try to discuss a follow-up plan after the release.

Don't worry about not conforming to the process, we welcome any contributors and are willing to trust them, trust is built gradually in the community :)

我需要再次强调：任何想要添加新功能的人（包括项目维护者、提交者）都需要在 issue 或 disscusion 中进行讨论，只有这样我们才能确认将其分配给谁，以及后续的发布时间表。我们欢迎任何贡献者，但不会合并未经讨论而未经讨论和确认的功能。

Got it, thanks for clarifying the process.
I actually created a discussion thread about the broader validation features right after submitting this PR. This current PR is just a small utility class - nothing fancy, just basic required field validation.
Should I wait for the discussion to conclude before this gets reviewed, or can this small utility be evaluated on its own? It's pretty minimal - just one class and one annotation.
Also, I see@wangmiscoding has PR#282 on similar stuff. Should we coordinate somehow?
Happy to follow whatever process works best for the project.

Probably won't be able to merge in 1.3.0 for a while (since we were planning to release it in the near future) We'll try to discuss a follow-up plan after the release.

Don't worry about not conforming to the process, we welcome any contributors and are willing to trust them, trust is built gradually in the community :)

Thanks@psxjoy! I really appreciate the welcoming attitude and the transparency about the release timeline.

I'm totally fine with waiting until after 1.3.0 - gives us more time to refine the approach through community discussion.

Looking forward to building that trust gradually and contributing meaningfully to FastExcel! 🙂