一連の複雑なPDF フォームがAdobe LiveCycle プラットフォームと Designer (バージョン 8.2) で生成され、インラインで表示されるエンドユーザー クライアントに Java ベースの Web アプリケーションによって提供されるアプリケーションがあります。これらのフォームには、いくつかの Javascript 検証コントロールによって表現されるアプリケーション ロジックと、ユーザーがさまざまなフォーム フィールドをコンパイルするときに動的に評価される表示/非表示条件が付属しています。PDF フォームが保存されると、基礎となるXML データが抽出されて保持され、後続の操作の基礎として機能します。
PDF の代わりにHTML フォームを構築するモデルとして、XML データ形式 (およびそれを定義する XSD スキーマ) の両方を維持しながら、Adobe LiveCycle テクノロジを中心とした、この一般的なアーキテクチャに代わるものを見つけるように求められました。1 つ、および現在 PDF フォームで表現されているアプリケーション ロジックのレベル。
XML フォーマットに関するこの強い要件があるため、フォームを作成できる代替案を探し始めました。また、改訂されたアプリケーションで、最初の XML データ モデルと最終的な HTML フォームの間の中間層をできるだけ少なくする必要があります。
Cocoon Frameworkの「ブロック」(つまりモジュール) であるCocoon Formsに出会いました。Adobe LiveCycle プラットフォームといくつかの類似点を共有しており、興味深い解決策のように見えます。
- XML関連技術に重点を置いています
- XML 自体は、フォーム モデルとフォーム テンプレートによるその表現の両方を定義するために使用されます。両方の DSL は XML に基づいています。
- さまざまなフォーム要素間の検証ロジックを表現する可能性
- フォームのクライアント側とサーバー側の間のシームレスな統合
Cocoon Forms を使った経験のある人はいますか? もしそうなら、私たちの簡単に要約されたシナリオに関して、それが実行可能な解決策と考えられるかどうか、誰かが私たちに知らせてくれますか?
事前にサンクス！