ini で設定したい

問題点

class/Plugin/Abstract.phpを導入した際に、
$this->configというプロパティが配列として宣言されています。

    /** @protected    array   plugin configure */
    protected $config;

これはいろいろ問題点があると思います。

• もともとプラグインの$this->configはEthna_Configオブジェクトを格納していた。同じ名前のまま中身がArrayに変わってしまうと、後方互換が損なわれる。
• class/Plugin/Handle/PearLocal.phpにおける$this->configはオブジェクトであり、一貫性がない。
• $configは慣習的にEthna_Configを指すので、ここだけ配列だと混乱のもとになる。
• 実際にはPlugin/Cachemanager*でしか使われていない。

改善案

その１ 名称を$this->configではなく$this->optとする。

その２ ソースコードが無駄に複雑になってしまっているので、
class/Plugin/Abstract.phpには実装せず、
class/Plugin/Cachemanager.phpに実装する。

上記２つの改善案を提案いたします。

• tmp ディレクトリ (というか template_c) に書き込みの権限がないとき真っ白な画面になってしまう

skel/www.css.ethna.css

背景画像が絶対URLになっていて、404 Not Foundになってしまっております。

例
background: url("http://ethna.jp/image/pagebg.gif");

ethna.jpサーバの状態に依存してしまうので、画像もソースコードと同梱した方がよいのではないでしょうか？

元: リリース後までを考慮した設定値の変更 http://sourceforge.jp/ticket/browse.php?group_id=1343&tid=16754

dev や prod など

http://ethna.jp/doc/install.html
こちらを見る限り Ethna 2.6.0(beat3?) がインストールされると思うのですが、
先ほどインストールを行ってみたところ、 Ethna2.5.0 がインストールされました。

http://www.php.net/manual/ja/migration53.deprecated.php

• ereg_replace

そもそもPHPUnitにかえちゃったしなんか代案考えるということで

array|string getTemplateDir( [string $index] )
replaces $smarty->template_dir; and $smarty->template_dir[$index];

Smarty setTemplateDir( array|string $path )
replaces $smarty->template_dir = "foo"; and $smarty->template_dir = array("foo", "bar");

Smarty addTemplateDir( array|string $path, [string $index])
replaces $smarty->template_dir[] = "bar"; and $smarty->template_dir[$index] = "bar";

etc.

2.5.0 と同じ dsn 記述をしたのですがDB接続できません．．

config で smarty のデリミタを変更している場合、unittest の標準テンプレートで表示できません。
Controller::getRenderer() で unittest 用の処理が記述されていますが、
それが呼び出される前に UnitTestCase が ctl->action_name を変更してしまうためです。

Controller::_trigger_WWW() であらかじめ呼び出しておけばよいでしょうか？

--- a/lib/Ethna/class/Controller.php
+++ b/lib/Ethna/class/Controller.php
@@ -1002,6 +1002,11 @@ class Ethna_Controller
         }
         $this->action_name = $action_name;

+        // アクションが __ethna_unittest__ の場合、事前にレンダラーを生成しておく
+        if ($this->action_name == '__ethna_unittest__') {
+            $this->getRenderer();
+        }
+
         // オブジェクト生成
         $backend = $this->getBackend();
         $session = $this->getSession();

From ML ([ethna-users:1253]):

Ethna_UrlHandler.php
requestToAction関数内、254行目の break;

以上の箇所で、
foreach ($action_map as $key => $value) ループを抜けていないようです。

$action, $action_match が他の条件で上書きされ、
$action_regexp_index の値だけが残る場合があり、誤動作します。

http://ml.ethna.jp/pipermail/users/2010-January/001193.html

Ethna の i18n まわりの処理が 2.5.0 stable では処理時間の半分近くを占めるという指摘があった。

http://twitter.com/hnw/status/5173554984

これを踏まえていろいろとコードを書き換えて見たのだが、有意な差を出すには至っていない。 ベンチマークは以下のapdを使ったものを参照。

http://www.mumumu.org/~mumumu/ethna_master_trace.txt

i18nの機能自体を必要としている人がそもそも思われる現状では、この遅いコードをデフォルト で有効にしておくことは問題であると考えられる。よって、以下の選択肢を検討していく。

1. i18n の機能を disable にするかどうかを選べるようにする(デフォルトdisable)
2. 高速な gettext 一本に絞る

【提案】

下記のようにUTF8と他の文字コードで往復変換して戻らないものをはじくというのはどうでしょうか？

    $tmp          = mb_convert_encoding($string, $dst, $src);
    $roundTripped = mb_convert_encoding($tmp,    $src, $dst);
    if ($string !== $roundTripped) {
        $this->ae->add($name, '{form} に機種依存文字は使用できません', E_FORM_INVALIDCHAR);
     }

チェックボックスやhiddenで、配列を受け渡しするとき
http://d.hatena.ne.jp/obys/20070422/1177253129

次の画面に進むと
ほげには配列を入力して下さい
と errors に格納され、うまく受け渡しが出来ないようです…。

htmlで
　＜input type="hidden" name="hoge[]" value="1" /＞
　＜input type="hidden" name="hoge[]" value="2" /＞

action で フォーム定義を
　'hoge' => array('type' => array(VAR_TYPE_STRING))

でNGです。

※また、validate() しない場合でも errors にこのメッセージが格納されます。
　（配列かどうかのチェックは強制動作する仕様なのでしょうか？）

etc/{appid}-ini.php
log/{appid}.log
についての提案です。

単純に、
etc/ethna-ini.php
log/ethna.log
とした方がわかりやすいのではないでしょうか？

■理由
① Google検索でヒットしやすいので、ノウハウを共有しやすい。初心者にやさしい。
　(例： .zshrcとか.emacsとかみたいに)

② tail -f とかするときにいちいちappidを考えなくて済む。
　　２つも３つも異なるサイトを運営していると、シェルでappidを打ち間違えたりします。
tail -f log/ethna.log のように名前が固定されている方が楽です。

ご検討よろしくお願いします。

メーリングリストが稼動していないようでしたのでブログに載せました。

http://www.remix.gr.jp/service/blog/2013/06/ethna_appobject.html

Ethna_AppObject.php内のfetchRow()を呼び出している５箇所。

636行目、650行目、692行目、706行目、793行目

$r->fetchRow( DB_FETCHMODE_ASSOC );ではないでしょうか。

Ethna 2.6 でもソースは同じようです。

私の思い違いでしたらスミマセン。 また、Github の使い方を間違っておりましたらスミマセン。

確認環境 　Ethna-2.5.0 　Smarty Version 2.6.26 　PHP Version 5.3.3 　CentOS release 6.4 (Final)

ethnaのEthna_DB_PEAR.phpがPEAR::DBに依存していますが、PEAR::DBがdepricatedになってしまっているので、他のライブラリ(PDOやMDBなど)にしてみてはどうかと思うのですが、いかがでしょうか。

2.5.0と同じ記述をしているのですが
getManager("user") で UserManager が取得できません

元: http://sourceforge.jp/ticket/browse.php?group_id=1343&tid=16105

ethna add-action-testでアクションのテストケースを作成し、unittest.phpを実行した場合、
Cannot access protected propertyのエラーが発生する。

Ethnaバージョン:
ethna-ethna-2.6.0beta3-0-g8ba873d

報告のみで申し訳ございません。

Ethna_* クラス群でメソッドがprivate宣言されていると、子クラス側から呼び出すことができません。

そもそもEthnaのアーキテクチャは、Ethna_*クラスをプログラマが継承して使うので、Ethna側は基本的にprotectedでよいと思うのですががいかがでしょうか。

「妥協」をスローガンにするなら、このprivateはちょっと厳しいと思います。

私が管理しているショッピングサイトでEthna2.6.0を導入しようとして、このprivateで苦労しています。

例

• Controllerで_trigger_WWWをオーバーライドすると、_getActionNameが呼び出せない
• ActionErrorでaddObjectをオーバーライドすると、_getActionFormと_getLogger が呼び出せない

元: http://sourceforge.jp/ticket/browse.php?group_id=1343&tid=16102

ethnaコマンドの add-entry-point は、アクション名を引数として取り、アクション名のエントリポイントを作成する挙動となっていますが、これは実際に使われているものなのかが疑問です。
作成すると、エントリポイント名のアクションも自動生成するのは、挙動として分けた方がいいのではないか。
アクション名ではなく、パス名として指定する必要があるのではないか。 仕様を要検討。
また作成されるエントリポイントが、app/APPID_Controller.phpへのパスがフルパスになっているので、相対パスへ変更する必要があると思います。