Proposal to Contribute DocumentComposer Functionality #185
Description
Proposal: Integrating DocumentComposer (Assembler + Builder) into the Codeuctivity fork
Hi! First, thank you for the work you’ve been doing to keep OpenXmlPowerTools moving forward. Since the original upstream repo has been mostly dormant for years, it’s been great to see this fork become the most active and reliable place for ongoing development.
Our small team (opendocx) has also maintained our own fork for a long time, and we recently rebased it on top of Codeuctivity’s because your improvements were both more extensive and more current. Over the past couple weeks we’ve submitted a few bug‑fix PRs as a way to contribute back, and we’d like to continue collaborating.
One larger feature we’ve developed is DocumentComposer, which integrates DocumentAssembler and DocumentBuilder into a unified workflow. It allows templates to drive insertion/concatenation of child DOCX content (static or dynamic), supports implicit/direct/indirect source modes, and performs all composition in memory. It aims to be backward‑compatible with existing usage of both tools. Read more about DocumentComposer here.
Before opening a PR, we wanted to check whether this is something you’d be open to reviewing. The changes required a few internal/private signature adjustments in both DocumentAssembler and DocumentBuilder, but we’ve kept them as minimal as possible and are happy to revise the approach based on your preferences. Right now the feature is spread across 3 or 4 commits, but I'll boil that down to a very clean PR if you're interested in looking at it further.
If the full feature isn’t something you want to merge right now, I would propose a "plan B": we could instead submit a much smaller PR that just renames DocumentAssembler's TemplateError class to AssembleResult, reflecting a more generic purpose (which would include, but is not necessarily limited to, errors). This makes the existing public API (which just has an "out bool" for when errors happen) easy to implement without breaking existing callers, but it also includes the minor function signature changes needed by our DocumentComposer extension, making it much easier to keep our forks in sync.
Our goal is to avoid long‑term divergence between forks and to contribute improvements upstream wherever possible. Happy to provide a draft PR or break the work into smaller pieces depending on what works best for you.
Thanks again for maintaining this fork — looking forward to your thoughts.