FAQ

ZKはAJAXのフレームワークであり、「リッチUI」と「低コストの開発費用」を兼ね備えるウェブアプリケーションの開発を補助するオープンソースです。 ZKはAjaxをベースにしたエベント駆動型エンジンと豊富なXUL・XHTMLコンポーネンツ集とマークアップ言語の集合体です。

• イベント駆動型エンジンはウェブ開発者に直観的なデスクトッププログラミングモデルをもたらしました。
• ZKが用意したすぐ使用できるXUL・XHTMLコンポーネンツブロックがウェブアプリケーションを豊富にします。
• ZUMLというマークアップ言語を使えばHTMLを編集する程度のレベルで リッチUIを作成することができます。

ウェブアプリケーションを開発するのに、なぜZKフレームワーク が必要？

ウェブアプリケーション開発用のフレームワークが既に多すぎますが、ZKを使用するのが本当に必要ですか？

既存のフレームワークではリッチなUIを実現できないか、または開発費用が高いという問題があります。

1994年、 zAppとOWLを手本としインフラを構築しました。 それはウインドウズ用の会計システムでした。 そして、2000年、　StructとWebWorksの成功例を見てJ2EE用の会計システムを開発しました。 この二つの経験からウェブアプリケーションが高い技術や条件が必要であることを痛感しました。また、開発コストもクライアント・サーバ方式と比べ、４倍も掛かります。最も厳しいのはCSSや画像を使用したにもかかわらず、ユーザーインターフェースの使いにくさは60年代科学用のコンピューター画面を彷彿させました。

そこでわれわれは考えました。それはウェブアプリケーションの本質的な問題なのか、それともプログラミングモデルが不適切だったからなのか。90年代デスクトップアプリケーションの成功を振り返ってみると、イベント駆動型コンポーネンツをベースにしたモデルが成功の鍵を握っていました。簡単に使用・開発できるというメリットで、このモデルは対話性を実現する最も適当な方法でした。果たしてこの方法はウェブアプリケーションにも適用できるのでしょうか？ いくつかの商用計画を開発してみたところ、答えが出ました。

ZKプロジェクトの目標は？

• ユーザーインターフェースについてはデスクトップと同等、またはより豊富な機能と対話性を求めます。
• 開発において、デスクトップと同等もしくはそれ以上の簡単さを目指します。
• 使用者同士が協力できる良い環境を作ることを目指します。

ZKの現状が知りたい。本当にSimple＆rich？

ダウンロードして 体験してみましょう。

• リストボックス・ツリー・ドラッグ＆ドロップ・自動補完・スライダ・タイマー・コンボボックス・音声など60以上のXULと80以上のXHTMLコンポーネンツをサポートします。
• サーバ中心システム。 クライアント・サーバ間の情報の同期は自動的に行います。
  「Ajaxの最も良い使い方は気楽に使うことです。」
• Java と EL でスクリプトを作成します。 JavaScriptは不要です。コンパイルも不要。独自仕様の表現やスクリプトはいりません。
• 簡単なスレッドモデルです。スレッドの事前・並行処理がいりません。制限なし、複雑なスレッドも実現できます。
• 柔軟性のあるスレッドモデルです。 ユーザーを気付かせなくアプリケーションを一旦停止・再開できます。 true server-side modal dialogsを提供します。
• テンプレートや同期技術の補助で、簡単に新しいコンポーネンツを開発できます。
• クライアント側のJavaScriptウィジェットを簡単にサーバ中心のウィジェットコンポーネントに編集し変換します。例：FCKエディタやDojo.
• jarファイルをクラスパスに入れるのと同様に、多彩なコンポーネンツでアプリケーションの機能を拡張することができます。
• 開放的な環境でコンポーネンツ・テーマ・ツールを共有します。
• 設定もコンパイルも不要です。 HTMLページを編集する程度のレベルでZUMLが作成できます。
• 他の条件やデザインパターンがいりません。JavaコードをZUMLページに盛り込むことで迅速なプロトタイピングができます。複雑な設計ではMVC等も使用できます。設計はフレームワークではなく、開発者のあなたが決めます。

使用可能なブラウザは？

ZKは次のブラウザをサポートしています。Internet Explorer 6+/7, Firefox 1+, Safari 2+, Mozilla 1+, Opera 9+ and Camino 1+.

サーバの条件は？

サブレット2.4+ またはJVM 1.4+対応のウェブサーバなら結構です。

ブラウザプラグインは必要？

他のAjaxソリューションと同様、ブラウザでのインストール・プラグインは不要です。

Swingを使わずXULを使う理由は？

ユーザーインターフェースを実現するには少なくとも三つの方法があります： プログラミング、グラフィックツールで編集かマークアップ言語で編集します。 複雑なユーザーインターフェースを表現するのに、プログラミングが一番適切ですが、非プログラマーにとって二番目と三番目の方法がやりやすいです。この二つの状況を考えた上、ZKはプログラミングとマークアップ言語両方とも対応することにしました。さらに、混在することも可能です。グラフィックツールについては後日どサポートする予定です。

独自仕様のコンポーネンツや言語を発明するより、ZKは最初に対応する言語として「XUL」を選択しました（その次はXHTMLでした）。しかし、ZKはXULには依存しません。すべての言語とは独立しています。つまり、XAML等今サポートしていないコンポーネンツや言語は将来個別に追加することが可能です。

Javaプログラミングに詳しいのであればSwingはとてもなの便利ですが、補助ツールがあっても初心者にとっては複雑しすぎます。

XULが認識できるブラウザを使用しなければならない？

ブラウザがXULに対応できるかどうか、ZKはかまいません。 ZKはXULまたはXHTMLコンポーネンツに対し、HTMLタグを付けることで各ブラウザとの相性問題を解決しました。ブラウザはそれを標準的なHTML・CSSもしくはJavaScriptとして認識できます。

一方、対応するコンポーネンツがあれば、ブラウザがXULを認識できる場合も問題ありません。

JavaScriptが認識できないブラウザは使用可能？

今のところDOMとJavaScriptに完全に対応できるブラウザしか使用できません。 しかし、スマートフォン等J2MEで開発された機器はどんどん増えています。それらの機器では簡易なブラウザしか搭載されていません。 幸いにZKの構成はJ2MEと類似したプラットフォームにポーティングすることは可能なので今開発されたアプリケーションは今後はそのままJ2MEでも使用可能となります。

外見と操作性をカスタマイズ化することは可能？

視覚的な効果はCSSで制御されていますので、簡単に変更できます。

APIが同様に、アプリケーションを修正しなくても、ひとつのコンポーネントをまったく別の形で表現することは可能です。 タブボックスが普通とアコーディオンの二種類があるのはそのひとつの例です。

ZKを使用するのに、どのような基本知識が必要？

PHPとRubyの成功からヒントを得て、ZKは「簡単にできる」というふうに設計されました。JavaとXULができればZKを始めることができます. MVCや他のデザインパターンを使用しない限り、オブジェクト指向が分からなくてもZKが使用可能です。

UIやプロトタイプの設計者にはJavaを知る、あるいは使う必要は全然ありません。 また、HTMLで開発する場合、XULを知る、もしくは使う必要はありません。

今まで使用していたフレームワークを諦めなければならない？

お使いになるプレゼンテーション層のフレームワークをZKで取り替えるのが本音ですが、ユーザーが既に既存のフレームワークに時間・コストをたくさん投入したことが分かっています。そこで既存のフレームワークを諦めず方法を探し出しました。ユーザーインターフェースをリッチにする部分だけ作り直せば結構です。既存のJSP・HTML・ポートレットページはZUMLを入れられ、ZUMLもそれらのページを入れることができます。

さらに、ZKは他のベンダーの応答をフィルターする便利なツールを提供しています。 また、ZUMLをJSR-168スタンダードのポータルと統合するポートレットも提供しています。

新しいコンポーネントは簡単に作れる？

簡単かどうかはコンポーネントの性質にもよります。エクセルのようなコンポーネントは簡単ではありませんが、ほとんどのコンポーネンツは簡単にできます。　実際、現に提供している60のXULコンポーネンツは二人のプログラマーが一ヶ月で開発したものです。（もちろんベテランのプログラマーです）

コンポーネンツの開発を簡単にするため、ZKはJSP等テンプレートを提供しています。また、クライアント側の視覚効果とサーバ間との同期をしやすい便利なツールセットも提供しています。

面倒なコンパイルを不要にする、コンポーネンツをjarファイルで出力するのに、ZKはDynamic Servlet　Page　(DSP)というテンプレートを提供します。それはJSPと類似していますが実行しているうちに自動的翻訳されます。　ZKが正式にリリースしたコンポーネンツはすべてDSPとして開発され、jarファイルでリリースされました。

FCKeditor、Dojo等を使い慣れているコンポーネンツを引き続き使用したいが・・・

ここ数年開発者にとってすばらしいことは、オープンソースコミュニティーの急速な成長です。 すばらしいAjaxコンポーネンツとウィジェットが開発・公開されました。

これらのコンポーネンツを簡単且つ有効に利用するのはZKの構造を設計する際重要なポイントでした。 Integrating FCKeditorに書かれた通り、FCKeditor を統合するのに200行のJava・JavaScript・HTMLしか使用しませんでした。またDojo の場合でも300行しか使いませんでした。

コンパイル不要とは？処理に時間が掛かるのでは？

ZKの使いやすさは静的なHTMLを編集するのと同等のレベルで、つまりいわゆるdrop-and-goです。 ZUMLを適当な場所にコピーするだけでZUMLをデプロイすることができます。 ZKはそれを自動的に検知し、リロードします。 ZUMLが読み込まれたら、ZKはZKページを処理が早いフォーマットに一時的に転換します。 そのフォーマットは常にキャッチされますので、処理の効率は下がりません。

JSPと違って、ZKはJavaコンパイラーに依存しません。 ただし、サードパーティーが提供したJSPコンポーネントを使用する場合Javaコンパイラーが必要となります。

多くのAjaxソリューションはブートストラップ法でHTMLページを読み込むが、往復に時間が掛かることはない？

往復に時間が掛かるのはウェブアプリ長年の問題です。特にサーバ・クライアントが遠く離れている場合は非常に重要な問題になります。　そのため、ZKは独特な方法でひとつのレスでページことの情報を得ます。 遅延時間（latency）は同じサイズの静的なHTMLページとほぼ同様です。

ZKは他のAjaxソリューションと同様、たくさんのJavaScriptが使われています。　ZKはそれらのスクリプトをモジュール化し、関連したコンポーネンツが使われ必要な場合だけ読み込みます。 また、ブラウザはJavaScriptをキャッチしますのでそれらのJavaScriptは最初の一回目だけ読み込まれます。

すべての処理はサーバ側で行われているが、処理に時間が掛かることはない？

アプリケーションからみれば、ZKはサーバ中心です。 サーバ・クライアントそれぞれのロードを決めるのはコンポーネンツの組み合わせです。

たとえば、”edit box”　というコンポーネントは、ブラウザが元々サポートするため、ほとんどクライアント側で行います。 また、リストボックス・ツリーも同じようにJavaScriptのサポートによりクライアント側で行います。 クライアント側にビジネスロジックを適用しない限り、ad-hoc Ajax apps　を使用すると ZK を使用するパフォーマンスはほとんど同じです。 (リッチユーザーインターフェースを実現する際).

市場に公開するリードタイムを短縮するため、コンポーネントの開発者はサーバ中心の方式を選択するのもできます（JavaScriptをできる限り使わない）。その方法で作られたコンポーネンツの拡張性が不足かも知れませんが、開発者はその後、アプリケーションをいじらずに拡張性を改善することできます。

Ajax技術はまだ発展途上の技術で、JavaScriptを使うとメモリーリークが発生することがあると聞いたが・・・

互換性がない、不具合だらけのブラウザインプリが原因で、JavaScriptでDOMを処理するのはとても大変です。 確かに正しくJavaScriptを使用しないとメモリーリークは発生します。 それはJavaScriptを使わないフレームワークを使用する理由のひとつです。また、ZKを公開した理由でもあります。 より多くの使用者が使っていただければシステムはより安定します。

IEはXULをサポートし、FirefoxはXAMLに対応するが、ZKを使用しても大丈夫？

心配する必要はありません。　ZKはサーバ中心のソリューションです。すべてのコンポーネンツはサーバ側で処理されます。 お客様の一覧を表示するのに、データベースにリクエストを送り、リストアイテムを作って表示させれば結構です。　すべての処理はサーバ側で行います。 ZKを使用して開発すれば、クライアント側の技術は分からなくても結構です。　それはデスクトップのアプリケーションを開発する際、クライアント側のビデオカードが何であれを気にしなくてもよいのと同じです。

一方、FireFoxがXULをサポートする特性は完全にクライアント側の技術です。サーバとコミュニケートしないアプリケーションを開発するのであれば、これはいい選択かもしれません。しかし、データベースから取得した情報をリストボックスに埋め込むような作業をする場合では、このような技術を使うとクライアント・サーバ間の通信は開発者がしなければなりません。

オープンソースであるZKでソフトウェアを開発したら、GNU GPL・LGPL/BSDライセンスでリリースするのは可能？

はい。　GNU GPL・GPL-同等ライセンス・または他のOSI認定のオープンソースライセンスでしたら問題ありません。 ライセンスの一覧は FSF.org と OpenSource.org ウェブサイトにてOSI-approved open source licensesを参照してください。

OSI認定のライセンスはGNU　GPLライセンスV2とは共通しないところがありますが、OSIに認定されたライセンスを使用するアプリケーションのであれば、ZKの使用はOKです。Potixはこの場合を例外として扱います。但し、すべてのソースコードをPotixまたはコードが必要とする第三者に提供する義務があります。

ライセンスの詳細はこちら