このページは削除されました。以前のリビジョンの一覧をチェックして、いつ・なぜ削除されたのか確認したり、過去の版にアクセスしたり、元に戻したり出来ます。
sastruts:action [Ore Base]
このページは削除されました。以前のリビジョンの一覧をチェックして、いつ・なぜ削除されたのか確認したり、過去の版にアクセスしたり、元に戻したり出来ます。
Super Agile Struts - Feature Reference
機能リファレンス SAStrutsで使われている機能の説明をします。 プロジェクト構成 SAStrutsでは、ルートパッケージの配下にactionなどのパッケージを作って、 そこに必要なファイルを格納します。 ルートパッケージ名は、任意の名前を指定することができます。 例えば、sa-struts-tutorialプロジェクトでは、ルートパッケージ名は、tutorialになっています。 ルートパッケージ名は、convention.diconで指定します。 sa-struts-tutorialプロジェクトでは、src/main/resourcesで次のように指定されています。 convention.dicon <components> <component class="org.seasar.framework.convention.impl.NamingConventionImpl"> <i
メッセージの渡し方 - Writing Some Code
生StrutsのActionクラスではsaveMessagesメソッドを使えば、ビューへメッセージを渡せますが、SAStrutsではどうやって渡すのか調べてみたら、ActionMessagesUtilというユーティリティクラスが用意されていました。 Actionクラスでの使い方は以下のような感じ。 public class HogeAction { public HttpServletRequest request; // 中略 @Execute(input = "index.jsp") public String submit() { ActionMessages messages = new ActionMessages(); messages.add(ActionMessages.GLOBAL_MESSAGE, new ActionMessage("xxxxxx")); // xxx
Seasar2(SAStruts,S2JDBC) 覚書き - 共通の前処理・後処理
***共通処理の実装場所の候補 ---- 候補としては下記３つがあるが、それぞれメリット・デメリットがある。 -Filter -RequestProcessor -ActionのInterceptor ***Filter ---- ****メリット -一般的なので、実装がわかりやすい。 -前処理としては、最初に実行できる。(Formの入力チェックよりも前に実行できる) -後処理としても、最後に実行できる。(JSPよりも後) ****デメリット -常にリクエスト全体に大して、処理が実行されるので、メソッド個別の処理がやりにくい。 -FormやActionのアノテーションを読み取った処理がやりにくい。 ****実装方法 -Filterクラスの作成 -web.xmlへのFilterクラスへの登録 ***RequestProcessor ---- ****メリット -Formの入力チェックよりも前
SAStrutsでセッションを使ったログインと認証 - Block Rockin’ Codes
認証の方法は悩みがちなポイントだと思います。コンテナ等の実装も含めると手段は色々あるし、一言に認証といっても、色々な業務ロジックが絡んでくることも多いからでしょうか。 今回はSAStrutsで、sessionとAOPを使ったスタンダードな方法を実装しました。 仕組みはいたってシンプルで、何らかのロジックで認証した後、ID等のデータをセッションに格納して、その有無でログイン済みかを確認するというものです。ログアウトはそのセッションを廃棄することになります。Webアプリケーションでは王道の方法だと思います。 この場合、認証のチェックが必要な場面で同じ処理が必要になるので、SAStrutsではセッションのチェックはメソッドを分けて、AOPでアクションに適応します。 今回は、全体的にログインしっぱなしでいて欲しいので、LoginAction以外では全てのアクションで確認します。 これにより、どのペ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
