Hi Shuxin,
Thanks for bringing up this proposal. I have used poi-tl extensively in
previous business scenarios; its document templating capabilities are indeed
quite comprehensive, and its plugin mechanism is very flexible.
Based on the current [DISCUSS] thread, I have a few questions I'd like to
further exchange thoughts on:
1. Regarding document format support
Since poi-tl currently only supports DOCX, will the design of fesod-doc
consider supporting both DOC and DOCX formats simultaneously (or perhaps
prioritize DOCX and gradually add support for DOC later)? There is still a
certain demand for the DOC format in some scenarios. If fesod-doc can be
compatible with both, it might be more beneficial for migration and practical
adoption.
2. Regarding template data models and styling expression
The template data in poi-tl is mainly passed in via two ways: Map and POJO:
When special formatting is needed, it can be handled using a Map, for example:
map.put("name", Texts.of("zhangsan").color("000000").create());
However, for POJOs, there is currently a lack of an elegant way to express
styles or other formatting requirements.
Could fesod-doc consider introducing annotations on POJO fields to describe
styles or other template-related metadata? Similar to the @ExcelProperty and
@ContentStyle annotations in fesod-sheet, this would allow users to declare
formats and behaviors directly on the POJO using annotations.
3. Regarding the functional focus of the module
In its overall design, will fesod-doc lean more towards "writing/generating
documents" scenarios (e.g., generating DOC/DOCX by filling templates)? Or will
it also consider providing relatively comprehensive "reading/parsing"
capabilities?
4. Regarding whether the API design style will follow fesod-sheet
The fluent API design of fesod-sheet is very clear, for instance:
FesodSheet.write().head().registerWriteHandler().sheet().doWrite()
I'd like to know if fesod-doc will adopt a similar design style, such as:
FesodDoc.write().withTemplate().registerWriteHandler().doFill()
Or:
Document doc = FesodDoc.write().build();
doc.addParagraphs();
Will this kind of API style be used as a reference direction for the design of
fesod-doc?
The above are some of my thoughts based on the current discussion (not
comprehensive). I'm very much looking forward to the future design directions
and practical experiences shared regarding fesod-doc.
Best,
Bengbengbalabalabeng
> 2026年3月18日 18:08，Shuxin Pan <[email protected]> 写道：
>
> Hi everyone,
>
> As outlined in our initial roadmap, Apache Fesod aims to provide
> comprehensive interfaces for document processing. To fulfill this
> vision, I would like to propose the development of a new Doc Module
> (fesod-doc).
>
> Why Doc Support?
> While we have a strong foundation in Excel, many users are looking for
> a unified experience to handle Word documents. Instead of focusing
> only on tables within Word, this module will provide full-document
> manipulation capabilities (paragraphs, styling, templates, etc.).
>
> We will primarily reference Apache POI for robust low-level support
> and poi-tl for its elegant, logic-driven template engine.
>
> Implementation & Stability:
> To ensure our existing releases and Excel features remain unaffected,
> I will use a strictly modular approach. All new code will reside
> within the fesod-doc module, maintaining complete decoupling from the
> core project.
>
> Commitment:
> I view this as a long-term task and am fully committed to maintaining
> and evolving this module over time. At the same time, this is a
> community effort—I highly welcome any interested contributors to join
> me in this initiative.
>
> I look forward to hearing your thoughts and suggestions on this direction!
>
> Best regards,
>
> Shuxin Pan (psxjoy)
> Apache Fesod PPMC Member
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
