プログラマ向けのインターフェイスでドキュメントを生成するためのライブラリを作成した経験をコミュニティと共有したいと思います。 golangにとって、このニッチは次のWebツールキットと同じくらい重要です。なぜなら、世代のためのレポートとツールの可用性は、血まみれの企業にとってgoの魅力を高めるからです。



レポートは複数のステップからなるプロセスです。 レポートツールは、レポートの作成、データベースの操作、フィルター条件の管理と値の計算、最​​終ドキュメントへの出力のさまざまな段階を自動化できます。 後者について説明します。

はじめに

現時点では、「golang odf」という検索クエリの結果には、多くの要望があります。 もちろん、「golang pdf」のリクエストでは、すべてがはるかにバラ色です。 しかし、オフィスドキュメントの形式で特定のレポートを生成するビジネスアプリケーションの開発における私自身の経験に基づいて、美しいPDFがユーザーのコンピューターに届くと、多くの場合、数字をチェックし、不一致を確認して、呼び出しますレポートは「すでに昨日」必要であるため、受信したファイルの図を修正する要求でサポートします。



解決策は、Word / RTF / ODF / etc形式のドキュメントを生成するか、PDFを編集することです（このための既製のツールがありますので、これはプログラマではなく管理者にとってより興味深いです）。 また、独自の形式でコメントにコメントする機会も残しますが、ここではODF生成について説明します。

ODFフォーマット

オープンドキュメント形式は、編集可能なオフィスドキュメント用のオープン形式です。 それをサポートする有名なオフィススイートのうち、OpenOfficeとLibreOfficeは区別できます。 現在、バージョン1.2の形式の標準は有効ですが、バージョン1.0との違いはほとんどなく、それらは主に組織的な順序です。 この規格はすでに数年前のものであるため、安定していると見なすことができ、その作業に依存することができます。 この形式は、さまざまな種類の文書、テキスト文書、スプレッドシート、プレゼンテーションなどを提供します。 レポートを保存するための優先形式は、私の経験では、テキスト（odt）および表（ods）ドキュメントです。



この規格では、ドキュメントモデルを構造化し、このモデルをXML形式で保存するためのルールについて説明しています。 技術的には、ドキュメントファイルは1つの大きなXMLか、いくつかの必要なファイルと無制限の数のその他のファイルを含むzipアーカイブのいずれかでなければなりません。 この形式は画像やその他のファイルを埋め込むのに便利なので、zipアーカイブ形式のドキュメントのみを検討します。



また、ODFがロシア連邦の国家標準であることに注意することも不必要ではありません。 また、Microsoft Officeは組織内で確固たる地位にありますが、Open Officeは多くの場合近くに配置され、代替の飛行場として機能します。

なぜ行くの？

どうして？ シンプルな言語、Googleサポート、活気あるコミュニティ、空いているニッチ。 そして、それはただ楽しいです。 また、信頼性の高いコードをjavascriptでコンパイルできるため、場合によっては、レポートを生成するメカニズムをクライアントに一般的に転送できるため、Webサービスの柔軟性が向上します。 さらに、複雑なマルチレベルレポートなどの難しいことに高速のネイティブコードを使用しないことは罪です。

図書館

ODFレポートとフォームジェネレーターを実装する必要があった2008年以来、私はかなり長い間ODFフォーマットを使用しています。 次に、プログラムのドキュメントを便利に（見たところ）生成するために、別の言語でコンポーネントを実装しました。 一般に、結果は満足のいくもので、私のコンポーネントはまだ機能しています。



数年の使用後、通常は多くのコメントが蓄積されました。それを根本的に修正し、ライブラリ全体をゼロから書き直すことにしました。 今は時間が興味深いので、創造的なかゆみの実装にGoエコシステムを選択しました。 しかし、一般的には、以前のバージョンのインターフェイスソリューションを実績のあるものとして維持しようとしました。



次に、形式についてより具体的なことを説明します。 これに慣れるために、ODF標準の概要を読むことができます。

プログラマーの観点からODFを操作する際の主な困難は何ですか？ それは、ドキュメントの可視コンテンツの変更が暗黙的にドキュメントモデルのいくつかの領域の変更につながるという事実にあります。 変更は、コンテンツ領域、スタイルの説明領域、zipパッケージのコンテンツに影響します。 同時に、XMLの特性により、目に見えない文字と戦うためのいくつかの手段がODF形式に導入され、生成ツールに追加の責任が課せられました。



もう1つの重要なポイントは、スタイルの再利用です。 コンポーネントは、ユーザーが作成するスタイルに従って、重複することなく最適に保存する必要がありました。

実装

このメカニズムをすべて実装するために、Formatterの概念が考案（スパイ）されました。 フォーマッタは、ドキュメントモデル、ドキュメントモデル自体、およびクライアントコードから隠されているが、クライアントコードのアクションを何らかの方法で制御および検証できる一連の補助データ構造に関する情報を含む集合体です。



ドキュメントモデルの場合、以前のバージョンでは冗長な純粋なDOMが使用されていたため、新しいバージョンではDOMなどの単純化されたデータ構造が使用され、Go標準ライブラリからの半手動マーシャリングによってXMLに変換されます。 ドキュメントモデルを操作するには、Carrier-Rider-Mapper（CRM）パターンが使用されます。 キャリアは記憶媒体であり、この場合はノードツリーです。 ライダーは、ツリーとその変更を実行するために使用されます-ランナー、木製データ構造では、スライダーがノードの位置を取得し、子孫のリストとこのノードの属性を実行することが特徴です。 このスキームのマッパーは、スライダーの助けを借りて、ドキュメントモデルで動作する高レベルのメカニズムです。ご想像のとおり、このスキームではフォーマッターです。



ドキュメント自体のコンテンツは、目的のネームスペースからの特別な名前を持つノードの形式で記述されます。 ノード属性も特別な名前空間に属します。 テキストエディタを開くと、美しいテキストやタブレットでさえ、ノードと属性のセットが解釈されます。 したがって、フォーマッタの主なタスクは、ノードとその属性を記録し、適切な場所に正しく記録することです。その名前と意味は標準で説明されています。 例：

<text：p>要素は段落を表します。これは、OpenDocumentファイル内のテキストの基本単位です。

段落要素を記述します。その内容は、段落スタイルが適用される段落として表示されます：ページ上の配置、行間隔など。



現時点では、既製のドキュメントを読んで変更するタスクを自分で設定していませんでしたが、このデータモデルはこれを可能にします。これは実装の問題です。



拡張性を高めるために、当初モノリシックなフォーマッタはいくつかの狭いものに分割され、ドキュメントの特定のセクション（ツリーノード）を記録する機能を実行しました。 ParaMapperは段落の内容を記録し、TableMapperはテーブルとその内容を記録し、ParaMapperはテキストをセルに記録します。 このアプローチにより、膨大な標準の必要な機能をポイントの努力で実装でき、時間とプロジェクトリソースを節約できます。



テキスト属性、文字テキスト、ページ上の段落の配置、およびその他の必要な属性は、一般化された属性生成メカニズムを使用して設定されます。

この属性またはその属性ファミリには、目的のスタイルを設定できる特別なビルダーが実装されています。

この作業の重要な特徴は、属性を設定しても、実際に文書に書き込まれることを意味しないことです。 実際には、これは次のような作業スキームにつながります。

• 記録用に準備されたデータ
• 将来のコンテンツ属性を設定する
• 設定された属性を受け取る記録されたコンテンツ
• ドキュメントに書き込まれた属性

新しい属性を記述するかリセットするまで、連続する各コンテンツはこれらの属性に関連付けられます。 特別なユーザー属性が割り当てられていないコンテンツに起因する、ドキュメントのデフォルト属性を設定する追加の機会。



ODF標準は非常に膨大であるため、私の作業では、レポートの生成に必要な最小限の機能のみを実装しました。 これらの機能には、テキスト属性（色、フォント、サイズ）、段落属性（配置）、テーブルおよびセル属性（境界線属性、色、線の太さ）、画像の埋め込みがあります。



主な努力は、拡張可能なフレームワークの形成に費やされました。これにより、必要な属性や新しい要素を、ライブラリコードを変更しなくても実装できます（新しいコードを記述する必要があります）。 興味深いことに、プログラマーのスプレッドシート形式は、テキスト文書の形式とほとんど同じに見えます。 MIMEタイプのみが変更され、ドキュメントのルート要素がテキストではないという事実のみが変更されます。 テーブル書き込みエンジンは、どちらの場合でも同じように機能します。 これは、 odf_test.goモジュールの例で確認できます。

例

健康状態とその使用方法を示す簡単な例。

package main import ( "odf/generators" "odf/mappers" "odf/model" _ "odf/model/stub" //      "odf/xmlns" "os" ) func main() { if output, err := os.Create("demo2.odf"); err == nil { //   defer output.Close() //    m := model.ModelFactory() //  fm := &mappers.Formatter{} //    fm.ConnectTo(m) //  ,       fm.MimeType = xmlns.MimeText //   fm.Init() //   fm.WriteString("Hello, Habrahabr!") //  generators.GeneratePackage(m, nil, output, fm.MimeType) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

より複雑な例は、プロジェクトリポジトリのodf_test.goファイル、demo / report.goにあります。

本格的な例では、 デモレポートが生成されました。

おわりに

最後に、ODFドキュメントの形成自体は複雑なものではないことに注意してください。 ライブラリの最初のバージョンと2番目のバージョンの主な目標は、レポートとフォームを生成するタスクでさらに使用できる便利なプログラムインターフェイスを提供することでした。 また、このようなインターフェイスの基本レベルは、Webアプリケーションのレポートが生成されることが多い単純なHTMLなど、他の形式からコンバーターを構築する可能性を開きます。



このアプローチの欠点の1つは、クライアントコード用の便利なインターフェイスを考案するために、標準をコードに変換するための膨大な手動作業が必要なことです。 私は、ODF標準全体のRelaxNG処理スキームを使用してこの作業の自動化を見ることは理にかなっていると完全に認めています。これは、自動化に便利な形式で形式の機能と制限を記述します。



Goで書いてレポートが必要な場合は、ここにあります。 オープンソースとチーム開発の精神は、ライブラリを広大なニッチにすることができます。 また、ODFからバッチモードでPDFを取得できるため、数字を編集したりレポートをノックしたりする機能を大幅に強化できます。

参照資料

ODF形式の説明： docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html

プロジェクトリポジトリ： github.com/kpmy/odf

デモ： yadi.sk/i/RghkBDHIgcey2