高岡です。

安定版 Ethna 2.5.0 をリリースしました。このリリースでは Ethna
2.5.0 preview4 から変更を加え、それ以後で発見されたバグの修正や
小規模な機能追加を行い、安定版としました。2.5.0 preview 5 以降で
加えられた大規模な変更は含まれていません。

2.5.0 では、2.3系と比較して、EUC-JP ではなく UTF-8 をデフォルト
としたこと、国際化、多次元配列等の新機能をメインとして、多くの変
更が加えられています。新機能については、以下のURLを参照してくだ
さい。

「言語とエンコーディングの設定」
http://ethna.jp/ethna-document-dev_guide-app-setlanguage.html
「プロジェクトの国際化」
http://ethna.jp/ethna-document-dev_guide-i18n.html
「多次元配列」
http://ethna.jp/ethna-document-dev_guide-form-multiarray.html
「フォームテンプレートへの変更」
http://ethna.jp/ethna-document-dev_guide-form_template.html
「動的フォームAPI」
http://ethna.jp/ethna-document-dev_guide-app-dynamicform.html

詳細な変更点は 以下のURLを参照してください

http://ethna.jp/ethna-document-changes.html#b00186c9

このリリースに伴い、2.5.0 が新たに安定版としてメンテナンスされます。
よって、2.3.7 以前のバージョンのサポートは打ち切られます。新たに
Ethna でプロジェクトを作成される方は、このバージョンを使用してくだ
さい。また、2.3.x から移行を行いたい方は、以下のドキュメントを参照
してください。

http://ethna.jp/ethna-document-dev_guide-misc-migrate_project230to250.html

----

ダウンロード、インストールは、sourceforge.jp 及び PEAR チャンネル
を通じて行うことが出来ます。

pear channel-discover pear.ethna.jp
pear install -a ethna/ethna

詳細は以下を御覧下さい。

http://ethna.jp/ethna-download.html

----

バグ報告は、このML、IRC、または、sourceforge.jpのチケットシス
テムよりお願い致します。

http://ethna.jp/ethna-community.html
http://sourceforge.jp/projects/ethna/ticket/

----

最後に、利用して頂いているユーザの皆様、フィードバックを頂いた
皆様、開発者の皆様等、Ethna に関わっている全ての皆様に深く感謝
致します。これからも宜しくお願い致します。

それでは、Enjoy, Ethna！

-- 
Yoshinari Takaoka
takaoka ＠ beatcraft.com

sotarok です

2009年10月10日15:59 Yoshinari Takaoka <takaoka ＠ beatcraft.com>:
> 高岡です。
>
> 2009/10/7 Yoshinari Takaoka <takaoka ＠ beatcraft.com>:
>> 2. preview4　を境にいったん区切ってしまう(2.5.0 preview4 をいったん2.5.0 にする)
>>    現在の git 版は PHP5 専用とし、2.7.0 なり 3.0.0 向けとして開発を続ける
>
> 結論としては、以下の通りいくことにしました。
> なので、2.5.0 final は区切りをつける意味で連休明けには出すように作業を進めます。
>
> - 2.5.0- preview4 にバグフィックスのバックポートを加えたものを2.5.0 final とする
> - 2.5.0 final は PHP4 と互換性を保つ
> - 現在の git 版は PHP5 専用とし、3.0.0 previewとして開発を続ける
>
> ＃間違っていたら指摘してください。

先日の ML でいただいたご意見をあわせ，
メンテナ間で話し合った結論として，これで間違いありません．

これをもって Ethna 公式アナウンスとします．

また，現行 2.3 系は， 2.5 のリリースに伴いサポート終了し，
2.5 は 3.0 リリースから1年程度でサポート終了する予定です．
（このあたりの具体的な日程などは今後またアナウンスいたします）

2.5.0 は近日中にリリースされる予定です．

よろしくお願いいたします．


--
sotarok

高岡です。

2009/10/7 Yoshinari Takaoka <takaoka ＠ beatcraft.com>:
> 2. preview4　を境にいったん区切ってしまう(2.5.0 preview4 をいったん2.5.0 にする)
>    現在の git 版は PHP5 専用とし、2.7.0 なり 3.0.0 向けとして開発を続ける

結論としては、以下の通りいくことにしました。
なので、2.5.0 final は区切りをつける意味で連休明けには出すように作業を進めます。

- 2.5.0- preview4 にバグフィックスのバックポートを加えたものを2.5.0 final とする
- 2.5.0 final は PHP4 と互換性を保つ
- 現在の git 版は PHP5 専用とし、3.0.0 previewとして開発を続ける

＃間違っていたら指摘してください。

どうぞ宜しくお願いします。

-- 
Yoshinari Takaoka
takaoka ＠ beatcraft.com

高岡です。

2009/10/8 http://www.remix.gr.jp/ <www.remix.gr.jp ＠ gmail.com>:
> 今年業務で唯一残っておりましたphp4案件もようやくphp5に移行が終わりました。
> php5以上必須では、やはりフレームワークは全面的に
> try〜 catch、throw Exception 方式になってゆくのでしょうか。
> これまで あちこちで、エラーオブジェクトを返すべきか、本来の値を返すべきか
> ふらふらしていましたもので・・・。

例外という素晴らしい機構があるのだから、少なくとも現在の Ethna_Error 方式を
続ける理由はないと思います。なので、そうなるでしょう。

PHP5 になるとやれることが山ほど増えるので、対応すべきことは上記の例外以外
にも、割とあったりします。

E_STRICT、例外、アクセス制御修飾子、(その他 マジックメソッド、メソッドチェイン
などの PHP5 ならではの機能、関数）... 夢は広がりん(ry

-- 
Yoshinari Takaoka
takaoka ＠ beatcraft.com

高岡です。

2009/10/8 あきら <akirainfoml ＠ gmail.com>:
> あきらです
>
>> 2. preview4　を境にいったん区切ってしまう(2.5.0 preview4 をいったん2.5.0 にする)
>>    現在の git 版は PHP5 専用とし、2.7.0 なり 3.0.0 向けとして開発を続ける
>
> 賛成です
> 次のバージョンは3.0がいいなと思います！

僕的な感覚からいうと今の 2.5.0 preview4 までの変更を 3.0 にするのは
大げさかな、と（笑

2.5.0 preview 4 までの変更は、ユーザーからみると当たり前だと思える部分を
当たり前に使えるようにしただけの話で、メジャーバージョンを上げるほどの強力な
変更を行っているわけではない、という認識を持っているからです。

sotarok が今強力に推進している Plugin まわりと 僕が進めている（つもりの）
ORM まわりの変更が入れば、3.0 にしてもよいのかもしれません。

これは感覚に頼った意見でしかありません。皆様の感覚もがしがしどうぞ。

> PHP4互換については、PHP4で新規開発をしてるメンテナが
> いないのであれば、積極採用することもないのかな？

僕が知る限り、アクティブなメンテナで Ethna + PHP4 で業務アプリを
開発している人は現在いません。それに加えて、PHP4 のサポートが打ち切
られてから1年以上たっているので、サポートする根拠はかなり薄まってきて
いると思います。

> とはいえ、2.3系がもう少しサポートされているのであれば
> 私はPHP4だと2.3を使うとは思います

どうしてもメンテしたい！　というアクティブなコミッタがいればサポート
されるんでしょうが、(多分）いないはずなので、2.5.0 が出れば 2.3.x 系の
サポートは打ち切ると思います。

-- 
Yoshinari Takaoka
takaoka ＠ beatcraft.com

高岡です。

2009/10/7 Sotaro KARASAWA <reg ＠ sotaro-k.com>:
>> 1. 現状のgit版を 2.5.0 final とし、preview5 以降を PHP5 専用として開発を続けてfinal
>>    まで突っ切る
>> 2. preview4　を境にいったん区切ってしまう(2.5.0 preview4 をいったん2.5.0 にする)
>>    現在の git 版は PHP5 専用とし、2.7.0 なり 3.0.0 向けとして開発を続ける
>
> たしかに，現状の2.5系はp5あたりからかなり変更がかかっているので，
> ・UTF-8化
> ・国際化機構
> の2点を主眼において，p4から2.5.0をリリースしても良いと思いますね．

あと、多次元配列もありますね。

> p5以降見つかったバグ関連はバックポートしてくる形で，
> 汎用Viewやプラグインに関する，変更は入れないという感じですね．
>
> ＃2.5系の開発が始まって，最初のpreview版が出てから相当たっていて，
> ＃preview4までで結構かわってるよね，という事実を忘れかけていました（苦笑

もう1年半近くになるんじゃないでしょうか。何やってるんだって感じですね＞自分

> ですので，僕も，2に賛成です．

2.5.0 preview4 + bug fix というのを 2.5.0 final として区切る、に僕も一票です。

>  そうなると，preview5以降は，PHP5に向けた2.7/3.0系として開発を続けいく感じですね．
> （将来的に見てPHP5.3どうするのかっていう問題があるので，バージョニングはちょっと気を使う．．．w
> やっぱり世間的には3.0でPHP5.3かしら．．．とか
> まあそれはよしなに．）

バージョンナンバーは割と重要だったりしますが、5.3 というのを重視して
コードを書き換えていくつもりなら、それも別に区切る必要があるかもしれませんね。

current git -> 2.7 or 3.0 ?
5.3 対応版 -> 3.0 or 4.0 ?

という感じでしょうか。一応案を出しては見ますが、僕は PHP5 系の中でバージョンを
区切ることにさしたる拘りを持っているわけではありません。

-- 
Yoshinari Takaoka
takaoka ＠ beatcraft.com

　お世話になっております。

　今年業務で唯一残っておりましたphp4案件もようやくphp5に移行が終わりました。
　php5以上必須では、やはりフレームワークは全面的に
try〜 catch、throw Exception 方式になってゆくのでしょうか。
　これまで あちこちで、エラーオブジェクトを返すべきか、本来の値を返すべきか
ふらふらしていましたもので・・・。

あきらです

> 2. preview4　を境にいったん区切ってしまう(2.5.0 preview4 をいったん2.5.0 にする)
>    現在の git 版は PHP5 専用とし、2.7.0 なり 3.0.0 向けとして開発を続ける

賛成です
次のバージョンは3.0がいいなと思います！

PHP4互換については、PHP4で新規開発をしてるメンテナが
いないのであれば、積極採用することもないのかな？

とはいえ、2.3系がもう少しサポートされているのであれば
私はPHP4だと2.3を使うとは思います

あきら

sotarokです

2009年10月7日13:22 Yoshinari Takaoka <takaoka ＠ beatcraft.com>:
> なので、PHP5のみにするにしても、ユーザーにわかりやすい形でバージョンを区切るのも
> ありだと思っています。2.5.0 preview4 を境に一端区切るのもアリかもしれません。
> 現状のままだと以下の 1. ということになるのでしょうが、2. も提案しておきます。
>
> ----
>
> 1. 現状のgit版を 2.5.0 final とし、preview5 以降を PHP5 専用として開発を続けてfinal
>    まで突っ切る
> 2. preview4　を境にいったん区切ってしまう(2.5.0 preview4 をいったん2.5.0 にする)
>    現在の git 版は PHP5 専用とし、2.7.0 なり 3.0.0 向けとして開発を続ける

たしかに，現状の2.5系はp5あたりからかなり変更がかかっているので，
　・UTF-8化
　・国際化機構
の2点を主眼において，p4から2.5.0をリリースしても良いと思いますね．
p5以降見つかったバグ関連はバックポートしてくる形で，
汎用Viewやプラグインに関する，変更は入れないという感じですね．

＃2.5系の開発が始まって，最初のpreview版が出てから相当たっていて，
＃preview4までで結構かわってるよね，という事実を忘れかけていました（苦笑

ですので，僕も，2に賛成です．

そうなると，preview5以降は，PHP5に向けた2.7/3.0系として開発を続けいく感じですね．
（将来的に見てPHP5.3どうするのかっていう問題があるので，バージョニングはちょっと気を使う．．．w
　やっぱり世間的には3.0でPHP5.3かしら．．．とか
　まあそれはよしなに．）


--
sotarok


2009年10月7日13:22 Yoshinari Takaoka <takaoka ＠ beatcraft.com>:
> 2009/10/6 Sotaro KARASAWA <reg ＠ sotaro-k.com>:
>> 表題の件ですが，2.5系に色々詰め込んでいるというのもあり，リリースが
>> 当初よりかなり送れています．
>>
>> そんな流れの中ちまたではいつのまにかPHP 5.3がリリースされ，
>> 今更 2.5 系を PHP 4 をサポート対象としてリリースすることに
>> 個人的にはあまり意味を見いだせなくなってきました．
>>
>> 今，PHP 4むけに 2.5 系を出すということは，
>> その後少なくとも（少なくとも，です）１年程度はそれをメンテするということになりますし．
>>
>> PHP 5.3 向けにするのはまだ先だとしても，
>> 基本的に 5.x 向けにしてもいいのかな，と思っています．
>
> 僕個人はこれまで 2.5.0 final まではPHP4サポートでありでね、と思っていました。
>
> ただ、いろいろあってここまでずれこんでいる以上(原因の一端は開発に時間を割けて
> いない僕にあります。すみません) 、今の git 版ではこの流れは意味なくね、という sotarok
> の感覚も頷けるものがあります。
>
> ひるがえって現在の最新コードを見ると、「2.5.0 preview4」 までと それ以後はかなり別
> 物になってしまっていると思います。このバージョンを境に 2.5.0 preview間の互換性が失
> われています。
>
> なので、PHP5のみにするにしても、ユーザーにわかりやすい形でバージョンを区切るのも
> ありだと思っています。2.5.0 preview4 を境に一端区切るのもアリかもしれません。
> 現状のままだと以下の 1. ということになるのでしょうが、2. も提案しておきます。
>
> ----
>
> 1. 現状のgit版を 2.5.0 final とし、preview5 以降を PHP5 専用として開発を続けてfinal
>    まで突っ切る
> 2. preview4　を境にいったん区切ってしまう(2.5.0 preview4 をいったん2.5.0 にする)
>    現在の git 版は PHP5 専用とし、2.7.0 なり 3.0.0 向けとして開発を続ける
>
> --
> Yoshinari Takaoka
> takaoka ＠ beatcraft.com
> _______________________________________________
> Ethna Users List
> users ＠ ethna.jp
> http://ml.ethna.jp/mailman/listinfo/users
>

ナガイ aka longkey1です。

> 2. preview4　を境にいったん区切ってしまう(2.5.0 preview4 をいったん2.5.0 にする)
>    現在の git 版は PHP5 専用とし、2.7.0 なり 3.0.0 向けとして開発を続ける

に一票。

2.5.0はPHP4でも動くということで、ここまで来ているので、ここに来て変わるのもどうかなと個人的には思います。
でも、previewとついたバージョンを業務に使うのもなんだか気持ち悪いし・・・ということで、どこかで区切りをつけて欲しいなと。

リソースの分散も避けたいですし、サポート関連については、結構バッサリいってしまっても良いのかもしれませんね。

-- 
M.Nagai

高岡です。

2009/10/7  <okuyama ＠ workgroup.jp>:
> おく＠Workgroupです。
>
>> 今，PHP 4むけに 2.5 系を出すということは，
>> その後少なくとも（少なくとも，です）１年程度はそれをメンテするということになりますし．
>>
>> PHP 5.3 向けにするのはまだ先だとしても，
>> 基本的に 5.x 向けにしてもいいのかな，と思っています．
>>
>> このあたりの感覚皆さんいかがでしょうか？
>
> 変わりつつあるEthnaも現状では使えないし・・・
> PHP4系の新規案件は(ありえ)無いし・・

新規で PHP4 はもうないでしょうね。流石に。
なので、「一応」サポートされています。という状態をいつまで続けるか、という
問題意識が sotarok にメールを投げさせたのだと思います。

> いまの所はそんな感じで、シンプルなCI使ってしまってます。
> 申し訳ないです。
>
> とにもかくにも、ゆるいのが好きなんですよね  ^_^;

Ethnaはコード以外の別の意味でも緩すぎる、という説があります（汗

-- 
Yoshinari Takaoka
takaoka ＠ beatcraft.com

高岡です。

2009/10/6 Sotaro KARASAWA <reg ＠ sotaro-k.com>:
> 表題の件ですが，2.5系に色々詰め込んでいるというのもあり，リリースが
> 当初よりかなり送れています．
>
> そんな流れの中ちまたではいつのまにかPHP 5.3がリリースされ，
> 今更 2.5 系を PHP 4 をサポート対象としてリリースすることに
> 個人的にはあまり意味を見いだせなくなってきました．
>
> 今，PHP 4むけに 2.5 系を出すということは，
> その後少なくとも（少なくとも，です）１年程度はそれをメンテするということになりますし．
>
> PHP 5.3 向けにするのはまだ先だとしても，
> 基本的に 5.x 向けにしてもいいのかな，と思っています．

僕個人はこれまで 2.5.0 final まではPHP4サポートでありでね、と思っていました。

ただ、いろいろあってここまでずれこんでいる以上(原因の一端は開発に時間を割けて
いない僕にあります。すみません) 、今の git 版ではこの流れは意味なくね、という sotarok
の感覚も頷けるものがあります。

ひるがえって現在の最新コードを見ると、「2.5.0 preview4」 までと それ以後はかなり別
物になってしまっていると思います。このバージョンを境に 2.5.0 preview間の互換性が失
われています。

なので、PHP5のみにするにしても、ユーザーにわかりやすい形でバージョンを区切るのも
ありだと思っています。2.5.0 preview4 を境に一端区切るのもアリかもしれません。
現状のままだと以下の 1. ということになるのでしょうが、2. も提案しておきます。

----

1. 現状のgit版を 2.5.0 final とし、preview5 以降を PHP5 専用として開発を続けてfinal
    まで突っ切る
2. preview4　を境にいったん区切ってしまう(2.5.0 preview4 をいったん2.5.0 にする)
    現在の git 版は PHP5 専用とし、2.7.0 なり 3.0.0 向けとして開発を続ける

-- 
Yoshinari Takaoka
takaoka ＠ beatcraft.com

おく＠Workgroupです。

> 今，PHP 4むけに 2.5 系を出すということは，
> その後少なくとも（少なくとも，です）１年程度はそれをメンテするということになりますし．
>
> PHP 5.3 向けにするのはまだ先だとしても，
> 基本的に 5.x 向けにしてもいいのかな，と思っています．
>
> このあたりの感覚皆さんいかがでしょうか？

変わりつつあるEthnaも現状では使えないし・・・
PHP4系の新規案件は(ありえ)無いし・・

いまの所はそんな感じで、シンプルなCI使ってしまってます。
申し訳ないです。

とにもかくにも、ゆるいのが好きなんですよね  ^_^;

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
WEB屋におすすめ、イメージは悪いですがテクニックには定評のある
ライブドアの居残り組です。

http://www.amazon.co.jp/gp/product/4797354364?ie=UTF8&tag=i023-22&linkCode=as2&camp=247&creative=7399&creativeASIN=4797354364

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2007/7/04
CM王国β版 リリース

http://cm-king.com/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
関西の人気霊感風水師 あーりん監修
『本格☆香港風水〜恋する護符〜』2009/9/17 オープン！

「EZ メニュー」→「カテゴリで探す」
　　→「占い・クイズ」→「東洋占い」→「本格☆香港風水〜恋する護符〜」

「Y!トップ」→「メニューリスト」
　　→「占い・心理」→「風水・オリエンタル」→「本格☆香港風水」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
スピリチュアルタレント疋田紗也が監修した占いサイト
『９つの貴石』2009/8/13 オープン！

「EZ メニュー」→「カテゴリで探す」
　　→「占い・クイズ」→「占い総合」→「9つの貴石」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
.    ・ .  +    ： ゜.   ‥     ゜.  ．
 ‥     ゜.  ．    .    ・.    ・ .  +
   ／  +    ゜.      ・ .  +    ：

★               アイ・ティ・コム
  彡彡ミ         奥山 敦二 (Atsuji Okuyama)
  )∂∂ｂ
 ( ー  人_＿
  ￣/）/    |
    |`￣    "＼

sotarokです

これはメンテナ向け＆ユーザ向けどちらにも関わることですので，
どなたでもご返信ください．是非是非ご意見ください．

表題の件ですが，2.5系に色々詰め込んでいるというのもあり，リリースが
当初よりかなり送れています．
そんな流れの中ちまたではいつのまにかPHP 5.3がリリースされ，
今更 2.5 系を PHP 4 をサポート対象としてリリースすることに
個人的にはあまり意味を見いだせなくなってきました．

今，PHP 4むけに 2.5 系を出すということは，
その後少なくとも（少なくとも，です）１年程度はそれをメンテするということになりますし．

PHP 5.3 向けにするのはまだ先だとしても，
基本的に 5.x 向けにしてもいいのかな，と思っています．

このあたりの感覚皆さんいかがでしょうか？


--
sotarok

早々のご回答どうもありがとうございます。

基本的なことで、わずらわせてしまいました。
あっさり解決いたしました。

考えられる記述方法を一通り試していたのですが、
どうも自分でアサインしていたフォーム定義
class Manage_ViewClass extends Ethna_ViewClass{
 function _setDefault(&$renderer){
  $renderer->setPropByRef( 'formDef', $this->af->getDef() );
    ：
と、てれんこにしていたようです。お騒がせいたしました。

あっといまにドキュメントにまで追記していただき、ありがとうございます。

高岡＠コードレビュー中 です。

2009/9/20 http://www.remix.gr.jp/ <www.remix.gr.jp ＠ gmail.com>:
> Ethna 2.5.0 preview3 以降の多次元配列に対応したフォーム についての質問です。
> http://ethna.jp/ethna-document-dev_guide-form-multiarray.html
>
> 早速試させていただいているのですが、例えば
>   var $form = array(
>       'User[name]' => array(
>           'name'          => '名前',
>           'type'          => VAR_TYPE_STRING,
>           'form_type'     => FORM_TYPE_TEXT,
>       ),
> 上記のフォームの値を、Smartyテンプレートから参照する場合は
> どうのように記述すればよいでしょうか？
>
> 従来のフォーム値を {$form.User} と参照するように、
> 上記の場合 {$User[name]} として参照しましたらコンパイルエラーでした。
> smarty変数 に assign する前にも配列として認識するように
> 別の変数で再定義すればよいでしょうか。

多次元配列としてSubmitした値は、アクション上では $User[name] という
連想配列の形式で参照できますが、Smarty上で連想配列を参照する場合は、

$form.User.name

という形でキーにピリオドを付けた形で参照します。これは、Ethnaの使い
方というより、Smartyの使い方に関するものです。

ドキュメントにも追記しておきました。

http://ethna.jp/ethna-document-dev_guide-form-multiarray.html#r0639827

どうぞ宜しくお願い致します。

-- 
Yoshinari Takaoka
takaoka ＠ beatcraft.com

お世話になります。

Ethna 2.5.0 preview3 以降の多次元配列に対応したフォーム についての質問です。
http://ethna.jp/ethna-document-dev_guide-form-multiarray.html

早速試させていただいているのですが、例えば
   var $form = array(
       'User[name]' => array(
           'name'          => '名前',
           'type'          => VAR_TYPE_STRING,
           'form_type'     => FORM_TYPE_TEXT,
       ),
上記のフォームの値を、Smartyテンプレートから参照する場合は
どうのように記述すればよいでしょうか？

　従来のフォーム値を {$form.User} と参照するように、
上記の場合 {$User[name]} として参照しましたらコンパイルエラーでした。
　smarty変数 に assign する前にも配列として認識するように
別の変数で再定義すればよいでしょうか。

　フォームヘルパは変数名を文字列として扱われるので問題ないようですが、
他の記述方法が「多次元配列 site:http://ml.ethna.jp/」などで見当たらなく
既出でしたり、私のドキュメント見落としでしたらすみません。

確認環境
　PHP Version 4.4.8
　Smarty 2.6.18
　Ethna 2.5.0 preview3
　Ethna 2.5.0 preview5

　ご回答いただきありがとうございます。大変参考になりました。

　単純化した例がイマイチでした。実際のところは、各商品別のアクションが混在しつつ複数の商品を一括で編集するような画面でした。

<form method="POST" action="{$script}">
商品コード{$form.cd[101]}
<input type="text" name="text[101]" value="{$form.text[101]}">
<input type="submit" name="action_up[101]" value="上へ"> 
<input type="submit" name="action_down[101]" value="下へ">
<input type="submit" name="action_delete[101]" value="削除">
商品コード{$form.cd[202]}
<input type="text" name="text[202]" value="{$form.text[202]}">
<input type="submit" name="action_up[202]" value="上へ">
<input type="submit" name="action_down[202]" value="下へ">
<input type="submit" name="action_delete[202]" value="削除">
    :
<input type="submit" name="action_Save" value="保存">
</form>

共通処理の基底クラス APPID_Action_Up から
APPID_Action_Up0
APPID_Action_Up1
APPID_Action_Up2
    :
APPID_Action_Up9
という具合にをアクションを継承してもよいのですが、配列にしたくなってしまうのでした。

　教えていただいた方法も含め、時間が出来たら挑戦してみようと思います。
　ありがとうございます。

ナガイです。

> アクションを配列にするのはご法度？
ご法度かどうかと問われれば、ご法度じゃない気がしますが、一般的でもない気がします。

> 詳細：http://www.remix.gr.jp/service/blog/2008/09/ethna.htm
見させて頂きましたが、画面設計の話のような気がしますね。

参考になるか分かりませんが、僕なら
・詳細ページへはGETで。
・一気に編集したい場合はチェックボックス＆POSTで
・もっとインタラクティブにやりたいなら適材適所にAJAXで（ポリシーに反すると思いますが）

ですかね。
伊藤さんがおっしゃられているように、セッションを上手く使うことでよりスッキリ出来る気もしますね。

ご参考になればと思います。


-- 
M.Nagai

伊藤です。

On 2009/09/05, at 10:36, http://www.remix.gr.jp/ wrote:
> 　各商品に編集要素（購入数指定して一括購入）などが含まれる 
> 場合に、
> どうしても上記のフォームとするため、
>
> <input type="submit" name="action_Detail[101]" value="詳細表示">
> 詳細：http://www.remix.gr.jp/service/blog/2008/09/ethna.htm
>
> のように、強引にアクションを商品番号の配列として  
> action_form で取得しております。


Actionを配列にしても、Controller::_getActionName_Form() 
を上手く定義してやれば
問題ないと思います。

配列なら、そのkeyをチェックして、action_*なら 
action候補に挙げて、valueは
どっかに取っておくとか。

でも、たかが（というとあれですが）このActionのために 
_getActionName_Formをいじるのも
微妙な気がします。

ショッピングカートのようなので、私でしたら無理にEthnaを
使わずに、選択した商品をCOOKIEかSESSIONかに保存し 
ておきます。

伊藤