Scenic3のAppUrlsに関するテスト - やさしいデスマーチ
sue445さんのエントリーにもあるように、Scenic3の弱点の１つにAppUrlsに各ページクラスを個別に登録しなくてはならないという事があります。これは、ページクラスからAPTを使ってControllerクラス群を生成し、さらにそれらのControllerをディスパッチするMatcherを生成する仕組みでScenic3が設計されている事に起因します。APTの制約として、1つのクラスから抽出できるアノテーションから複数のクラスは生成できるのですが、幾つかのクラスに分散したアノテーションをまとめる事はできないのです*1。したがって、次のような欠点があるのです。 Controllerクラスが増えすぎずStrutsライクにコードを書けるため結構使いやすいのですが、Pageクラスを追加する度にAppUrlsにも対応するMatcherクラスを追加しないといけないのが難点です。 解決方法の１つとし
Slim3 pluginでScenic3の使い方 - やさしいデスマーチ
Slim3には簡単にプロジェクトを作成する為に使えるEclipse pluginがあります。@tomotaro1065 さんが中心になって作られていますが、ご厚意でScenic3の対応もしていただいています。ですが、自分で使ってみて使い方が解らないのではないか？と気付きました。そこで、Scenic3の仕組みを含めてチュートリアルを書く事にします。内容は後でドキュメントに反映させるつもりです。 Scenic3ってなにさ？ scenic3は t2 frameworkのようなPageクラスをslim3で実現するslim3の拡張ライブラリです。 Scenic3はSlim3を薄くラップしたライブラリで、Slim3の設計思想である「"Simple" and "Less Is More"」を踏襲しつつ、1つのPageクラスに複数のアクションメソッドを記述できるようになります。spin-upへの影響は最小
Scenic3 によるRESTサポート - やさしいデスマーチ
Scenic3はSlim3のController層を薄くラップした拡張ライブラリです。Slim3では1アクション（URL）に対して１つのControllerを作成するシンプルなデザインですが、どうしてもControllerの数が多くなってしまいます。関連するアクションは１つのクラスにまとめ、アクションメソッドを複数定義する設計を好む人にとってはやや窮屈な仕様です。Scenic3ではそんな人達のために、複数のControllerクラスを1つのPageクラスに定義する手段を提供しています。 一方、REST風のAPIを設計する場合は同一URLに対して異なるHTTPメソッドを割り当てる事になります。例えば、あるモデルに対する取得と削除は次のような同じURLとなります。 http://yourdomain/item/{id} idにはモデルを識別する一意の値が指定されます。同一のモデルに対する操作は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
