リッチレットはorg.zkoss.zk.ui.Richletインターフェースを実装しなければなりません。org.zkoss.zk.ui.GenericRichletクラスを拡張することで、メソッドを実装する影響を最小にすることができます。
こうして、指定されたURLが要求されたとき、serviceメソッドが呼ばれ、ユーザーインターフェースを作成できます。
package org.zkoss.zkdemo;
import org.zkoss.zk.ui.Page;
import org.zkoss.zk.ui.GenericRichlet;
import org.zkoss.zk.ui.event.*;
import org.zkoss.zul.*;
public class TestRichlet extends GenericRichlet {
//Richlet//
public void service(Page page) {
page.setTitle("Richlet Test");
final Window w = new Window("Richlet Test", "normal", false);
new Label("Hello World!").setParent(w);
final Label l = new Label();
l.setParent(w);
final Button b = new Button("Change");
b.addEventListener(Events.ON_CLICK,
new EventListener() {
int count;
public void onEvent(Event evt) {
l.setValue("" + ++count);
}
});
b.setParent(w);
w.setPage(page);
}
}
サーブレットのように、initとdestroyメソッドを実装して、リッチレットが読み込まれるとき、初期化、または破棄できます。
サーブレットのように、リッチレットは一度だけ読み込まれて、関係しているURLにすべての要求を提供します。
サーブレットのように、リッチレットは作成されて、同じURLに共有されます。つまり、サーブレット(少なくともserviceメ ソッドは)はthread-safeでなければなりません。
一方、コンポーネントは共有できません。どのデスクトップも独立したコンポーネントのセットを 持ちます。そのため、ほとんどの場合では、リッチレットのデータメンバーとして、コンポーネントを保存するのはいい方法ではありません。
この問題を解決するのに多くの方法があります。代表的な例は以下に示すように、一つのデスクトップに一つのクラスを使用してコンポーネントを保存します。
class MyApp { //one per desktop
Window _main;
MyApp(Page page) {
_main = new Window();
_main.setPage(page);
}
}
class MyRichlet extends GenericRichlet {
public void service(Page page) {
new MyApp(page); //create and forget
}
}