關(guān)于Charity Auction Organizer

CharityAuctionOrganizer.com 提供了一個平臺，允許非營利組織進行籌款拍賣。這包括生成大量支持現(xiàn)場活動的文件，包括拍賣目錄、投標(biāo)人聲明、捐贈者收據(jù)和郵寄標(biāo)簽。

以前，這些文檔生成為基于固定模板的 PDF。用戶希望能夠自定義這些表單的外觀，并且隨著時間的推移添加大量特定選項以設(shè)置字體、顏色和更改對齊方式以及包含的內(nèi)容。

然而，組合的數(shù)量是無窮無盡的，簡單地添加越來越多的選項永遠不會為用戶提供他們想要的所有靈活性。

Aspose.Words for Java 最新下載

要求

需要的是一種讓非技術(shù)用戶使用他們已經(jīng)熟悉的工具設(shè)計文檔的方法，該工具提供豐富的格式和布局選項。然后可以將這些文檔作為模板上傳，這些模板填充了我們數(shù)據(jù)庫中托管的內(nèi)容。

最強大和最常用的選項是 Microsoft Word。我們需要一種方法來獲取用戶提供的 Word 文檔并在服務(wù)器端執(zhí)行合并，生成文件供用戶下載。

解決方案

Aspose.Words提供了用于訪問和生成 Word 文檔的靈活 API，并支持針對自定義數(shù)據(jù)源調(diào)用本機 Word 郵件合并功能。

我們的第一個原型實現(xiàn)了 IMailMergeDataSource 接口，以將數(shù)據(jù)庫中的數(shù)據(jù)輸入郵件合并過程。這種技術(shù)運行良好，并且針對Aspose.Words API的代碼非常少。

但是，它有一個主要缺點：它要求用戶使用 Microsoft Word 郵件合并字段來實現(xiàn)模板。雖然郵件合并字段適用于郵件標(biāo)簽等簡單文檔，但對于更復(fù)雜的結(jié)構(gòu)，它們很快就會變得不可用。

例如，一個簡單的條件塊如下所示：

這種語法對于我們的客戶來說太復(fù)雜了，無法維護，而且很容易出現(xiàn)格式錯誤。

此外，Word 郵件合并支持并通過 IMailMergeDataSource 公開的數(shù)據(jù)模型也不容易支持分層數(shù)據(jù)。我們有很多嵌套數(shù)據(jù)結(jié)構(gòu)的案例，它們不容易映射到 Word 的郵件合并區(qū)域概念。

增強的郵件合并

相反，我們需要一個更靈活的解決方案。Aspose Words 生成的郵件合并語法已經(jīng)支持一些擴展：使用 mustache 模板語法處理簡單字段值的能力。我們需要擴展這個概念來處理更高級的流控制原語。

因此，我們沒有使用內(nèi)置的郵件合并功能，而是通過 Aspose API 實現(xiàn)了一個自定義合并引擎，該引擎使用在文檔的正常流程中作為文本編寫的控制原語。

使用新語法的等效條件塊很簡單：

所有文本都只需輸入，根本不需要插入合并字段。
除了使用 mustache 模板語法評估表達式之外，還實現(xiàn)了幾個控制塊：

• {% foreach %} 用于迭代一組記錄
• {% row %} 用于在表中為集合的每個成員創(chuàng)建行
• {% sum %} 通過對集合求值來計算總數(shù)
  

特別是，{% row %} 原語可以很容易地生成目錄，其中每一行都由數(shù)據(jù)源中的不同記錄填充。這是許多類型文檔的非常常見的要求。

將這些概念放在一起會產(chǎn)生如下所示的模板：

并產(chǎn)生如下輸出：

Aspose Words API 使得迭代文檔結(jié)構(gòu)和操作樹節(jié)點變得非常容易。

甚至像在文檔中插入圖像這樣的操作也需要很少的代碼來實現(xiàn)。

技術(shù)細節(jié)

合并引擎的第一遍需要將文檔結(jié)構(gòu)轉(zhuǎn)換為規(guī)范形式，其中分布在多個“運行”節(jié)點上的控制節(jié)點被折疊成單個運行。

模板的第二遍通過克隆規(guī)范模板然后查找控制塊運行來工作。然后使用數(shù)據(jù)模型中的記錄對這些進行評估。

對于重復(fù)控制塊，這需要克隆文檔的任意部分，遞歸地評估其中的任何控制塊，并將最終內(nèi)容插入回文檔中。

Aspose.Words 可以非常直接地對文檔執(zhí)行這些轉(zhuǎn)換，并在模板中找到的各種類型的內(nèi)容之間提供一致的導(dǎo)航模型。

歡迎下載|體驗更多Aspose產(chǎn)品