そのような場合はAllMessagesまたはMessagesを使います。「全ての」の意味をちょっと説明する必要があります。Teedaでは、エラーメッセージを大きく2つに分類しています。前者は、arg1Messageなどで定義しているものたちだと思ってください。後者はそれ以外で発生したエラー全てをさします。AllMessagesはこれら全ての例外を一括で表示します。Messagesは、どういったものなのでしょうか。Messagesは上記の後者だけを表示します。適切な場所にmessageを埋め込まないといけません。このあたりは画面表示上の都合で使い分けることを想定しています。†Converterは、値の変換をする機能です。描画する直前にStringに変換する機能を持っています。下記にサンプルを示します。†Validatorと同様、Converterもさまざまな種類のものを用意しています。通常、Converterに関しては、一般的なprimitiveな値のものは自動的にConverterによる型変換が入るため、意識する必要はありません。型変換が明示的に必要な場合は下記のConverterをアノテーションで指定してください。†SelectOneMenuとはいわゆるプルダウンの項目のことです。SelectOneMenuでは下記のようにHTMLテンプレートで記述します。selectタグで始まり、idにItemsをつけたList/配列のプロパティがPageクラスにある場合にSelectOneMenuコンポーネントであるとTeedaは認識します。aaaItemsというList/配列のidでも認識します。id="aaaItemsMessage"/></form></body></html>Page側は下記のように記述します。aaaItemsはListまたは配列で記述します。List/配列の中身はDtoまたはMapで記述することができます。SelectOneMenuで選択された要素として、プロパティaaaを準備しておきます。null;}}Itemsの中身をDTOで記述する場合、Dtoはvalueとlabelという二つの要素は最低限持たなくてはいけません。下記のようになります。value;}}ではMapの場合はどうなるでしょうか?Mapの場合はもっと簡単です。下記のように、label、valueという名前で各Mapに登録しておいてください。ちなみに下記例では、初期表示時の選択項目を値2を持つBBBBという項目にしています。プルダウンに一番最初にでる文字列)を含めたい場合はどうするのでしょうか。必要かどうかを見ています。必須チェックなし→NullLabelありを基本的な挙動としています。選択してくださいとなっていますが、これはMessages.propertiesに定義してあるので容易にJSFの仕組みで入れ替えることが可能です。挙動として全てのアプリケーションでNullLabelを出したいなどの要望もあるでしょう。その場合はteedaCustomize.diconでカスタマイズすることが可能です。下記のように記述します。</property></component>これでアプリケーション全体でNullラベルを必須とすることができます。次はRadioボタンを選択する、SelectOneRadioを使ってみましょう。SelectOneRadioは、htmlには下記のように記述します。spanタグで始まり、idにItemsをつけたList/配列のプロパティがPageクラスにある場合にSelectOneRadioコンポーネントであるとTeedaは認識します。id="aaaMessage"/></form></body></html>SelectOneMenuとほとんど変わりません。Pageクラスは以下のようになります。†SelectBooleanCheckboxはYES/NO形式の簡単なチェックボックスのコンポーネントです。†SelectManyCheckboxは複数選択可能なチェックボックスのコンポーネントです。†Conditionは、表示/非表示をPage側の条件によって切り替えるためのコンポーネントです。†ForEachはPage側のList/配列を繰り返すためのコンポーネントです。†Teedaの状態維持のポリシー、それは状態をなるべくTeedaで持たないということです。状態はHTML側に埋め込むまたは、サーバサイドのpersistence層で保管するようにしてください。Teedaでは推奨しています。†ItemsSaveは、Base64でPage側で持つList/配列をそのまま書き出して次画面に受け継ぐための機能です。†Teedaのライフサイクルは主にJSFのライフサイクルのとおりになっています。詳細記述)これをPOST-REDIRECT-GETのPRGパターンでまわします。PRGパターンは下記参照。†PRGパターンとは、POST-REDIRECT-GETの組み合わせでHTTPでsubmitされたデータを処理する技法のことです。従来のforwardベースのsubmitでは以下のような問題がありました。URLの表示がずれるPOSTした後に画面がRELOADされたときに再度POSTされてしまう戻るボタンRELOADしたときにブラウザの警告メッセージが出るこのような問題への対処のための技法がPRGパターンです。PRGでは、POSTとGETで役割を分担しています。POSTでサーバ側のModelの状態を更新、REDIRECTでGETへ受け渡し、GETでは画面の描画というように分かれています。†Pageクラスにある特定のメソッドを記述しておくと、Teedaのライフサイクルの特定のタイミングで呼ぶことが出来ます.それがinitialize、prerenderです.initializeはPageクラスが初期化されるときに呼ばれます。呼ばれるのは、Pageが初期化されたときの一回だけです。prerenderは、画面が描画されるタイミングで毎回呼ばれます。動作するロジックを記述するタイミングを得ることができます。プロパティを持っていれば、前画面名を渡すようになっています。以下のようにPageにpreviousViewIdというプロパティを持っていると、Teedaが自動的にインジェクトしてくれます。同一のページであることをpostbackといいます。TeedaではpostbackかどうかをPageクラスで認識することができます。postbackされてきたものかを判定することが出来ます。金額入力コンポーネント。カンマ区切りになります。日付入力コンポーネント。YY/MM/DD形式をある閾値を認識して、YYYY/MM/DDに。Messageにします。id="messages"/>を記述します。一般的に画面の上のほうに出すことが多いようです。id="allMessages"/>をHTMLに記述します。†ある例外のときにエラーページへ遷移させる機能。自動で行数がエラーメッセージにつく。メッセージを集約したい場合は、アノテーションで記述する必要がある。†Page側で動的にHTMLの属性の値を変更するやり方について。†idについての細かいルールを下記に記述します。idでは基本的に英数字と_(アンダースコア)しか使えない同一のidのものを複数回表示する場合、-(ハイフン)で記述するそのため、ハイフンから後ろは無視される。idには、Camel式での記述を推奨します。†label.propertiesから動的に値を取り込める。lookupのロジックは、サブアプリケーション内label.propertiesから、HTML名.idで探索サブアプリケーション内label.propertiesから、idで探索web直下のlabel.propertiesから。†idをふっておくと、label.propertiesから動的に変更することができる。†Teedaでは、遷移元と遷移先に同じプロパティがあれば自動的に引き継ぎます。場合によっては、引き継ぎたくないこともあるでしょう。このときに使うのがTakeOverアノテーションです。TakeOverアノテーションは、メソッドに指定します。@TakeOver(type=TakeOverType.NEVER)の場合、次のページに何も引き継ぎません。bbbプロパティのみを引き継ぎます。bbb")のように書くこともできます。bbb以外のプロパティを引き継ぎます。value="commit"/>のようにdoOnceではじめると、TransactionTokenが発行される。Tokenはサーバ側で管理され、クライアント側でもDoubleSubmit防止のJavaScriptがrenderされる。†doFinishでは、サブアプリケーションスコープ内で管理しているプロパティを全てクリアします。†デザイン確認のためだけのタグなどは、id="mockXxx"のように"mock"で始まるidのタグで囲むことで、実行時にはレンダリングされないようになります。各規約および規約のチェック順について記述する。†TeedaAjaxについて、書いていきます。サーブレット以外にもポートレットして動作することをサポートしています。サポートする実装の一つといえます!)。ついてもポートレットをサポートしているので、サーブレット環境での開発と変わることがなく、ポートレットアプリケーションの開発が行えます。†まず、ポートレットについて、簡単に説明します。ベースのウェブコンポーネントで、プレゼンテーション層を情報システムに提供する交換可能なユーザーインターフェースコンポーネントとして、ポータルによって使用される(PLT.2.2)と定義されています。ポータルとはウェブベースアプリケーションで、表示、シングルサインオン、異なる発信元からのコンテンツ集約を提供して、情報システムのプレゼンテーション層を提供する(PLT.2.1)と定義されています。仕様的な定義は以上のような感じですが、簡単にまとめると、ポートレットはポータル(サーバー)上の小窓(フラグメント)で、リクエストを処理して、コンテンツをその小窓の中に表示するものです。そのための仕様を定義しています。習得する必要があります。使う場合は別ですが)。利用することでウェブアプリケーションを作成する感覚で、ポートレットを作成できてしまうわけです。開発を知っていれば、その知識をそのまま利用して、ポートレットの開発も行えます(ポータル固有の機能を利用する場合以外は、別途、ポートレットの開発方法を学習する必要はありません!)。作成されたウェブアプリケーションをポートレットにするためには、以下のことを行うだけでポートレットになります。利用していると思います。ポートレットがサポートされます。定義されているポートレット配備子です。ポータルサーバー上に表示するポートレットの情報を記述します。以下のような内容をこのファイルに記述します。要素の値には、ポータルにより利用される一意なポートレット名が入ります。要素の値がその説明になります。変更する必要はありません。ポートレットで表示されるポートレットには、表示モードや編集モードなどいくつかのモードがあり、たとえば、ポートレットの小窓の右上にある編集ボタンを押すと、編集モードが呼ばれます。要素としてサポートするモードを指定できます。要素を変更してください。その短いタイトルで、ポータルがモバイル環境で表示されるときに短いタイトルが必要なときに表示されます。区切りで複数指定できます。ポータルのポートレット一覧で検索するときなどに利用されます。下に保存してください(他にもいろいろな要素がありますが、必要に応じて、追加してください)。ファイルを追加します。それぞれ以下のところから入手できます。タグなどが含まれます。タグより下の部分しか表示する必要はありません。ファイルを作成してください。ファイルは、ポートレットアプリケーションです。ファイルを各ポータルの配備手順に従って、配備してください。†JSFについて記述。HTMLとどうやってマッピングしているかを記述。†テストの仕方について。†Teedaで薦める開発スタイル、それは段階的な開発です。従来のJavaの開発では、まとまった機能を作りこんでからサーバを起動して確認するといった非常にわずらわしい手段を取っていました。一方で、LLな言語(RubyやPerl)では書いたものをその場で動かし確認するというスタイルで開発されています。自分が書いたコードとそれがどう動くかというフィードバックのサイクルが非常に短いのです。通常のJava開発ではこのような開発スタイルをとることはできません。Seasar2.4のHotDeploy機能を使うと、これと同じことができるようになります。イメージしてみましょう。Tomcatをあげっぱなしで、HTMLを書きます。Mockとして簡単に動作するところまで作ってみてください。次にDoltengでPageクラスを作ります。Ctrl+5を押すだけで後はちょっとした設定を入れるだけでPageクラスは作られます。最初には何かエラーがでるかもしれません。これを修正して、ブラウザから再度確認します。このちょっと修正、すぐ確認を繰り返すのです。フィードバックループをたくさんまわしてください。非常に効率的にさくさく作業が出来て、変に一気に作らなくちゃいけないというプレッシャーも無いはずです。効率が良いだけじゃなく、気持ちよく開発ができるのではないでしょうか?さくさく開発、すぐ確認。これがTeedaが進める開発スタイルです。†Seasar2.4の新機能の一つにSmartDeployというものがあります。これによって、開発者がdiconを書いてコンポーネントを登録する必要はほとんどなくなり、ほんとうにしなければならない開発に専念することができます。SmartDeployは大きく3種類に分かれます。HotDeployCoolDeployWarmDeploySmartDeployのどのmodeで動いているかは、http://localhost:8080/your_war/teedaServlet?command=listとしてもらえればわかります。http://d.hatena.ne.jp/shot6/Seasar-userのMLでも受け付けています。†Teedaは沖縄の言葉で太陽という意味です。