ASP.NETでJavaScriptからポストバックを発生させる方法

ASP.NETアプリケーションをコーディングしていて、JavaScriptからポストバックしたいというケースがあります。例えば、検索結果の一覧をテーブルで表示しており、任意のセルをクリックした時に詳細を表示する画面へ遷移するケースなどです。

こういう状況に対応できるのが、次のクラスとインターフェイスです。

• ClientScriptManager
• IPostBackEventHandler

まず、JavaScriptのイベントハンドラに対して、ClientScriptManager.GetPostBackEventReferenceで取得した文字列を呼び出すように実装します。このとき、引数として渡した文字列が、次で実装するポストバックイベントハンドラの引数になります。ClientScriptManagerオブジェクトは、Page.ClientScriptから取得できます。

class MyPage : Page {

     protected void Page_PreRender(object sender, EventArgs e) {
         var args = "xxx"; // 例えば、詳細情報を表示するためのプライマリキー
         var js = ClientScript.GetPostBackEventReference(this, args);
         Table1.Rows[0].Cells[0].Attributes.Add("onclick", js);
     }

}

次に、ポストバックを受けるクラスが、IPostBackEventHandler.RaisePostBackEventを実装します。

// 上のクラスへIPostBackEventHandlerを実装
class MyPage : Page, IPostBackEventHandler { 
    ...
    public void RaisePostBackEvent(string eventArgs) {
        // 例えばセッションへeventArgsをセットして詳細ページへ遷移する
        Session.Add("key", eventArgs);
        var detail = ResolveUrl("~/MyDetailPage.aspx");
        Server.Transfer(detail);
    }
}

以上でJavaScriptからのポストバックが機能します。私が最初に思いついたのは、CSSで非表示にしたボタンをJavaScriptからクリックするという方法でした。しかし、こちらのほうが何倍もスマートだと思います。

ClientScriptManagerには、他にも様々なメソッドがあります。まだまだ便利な機能がありそうです。

参考：

ClientScriptManager
IPostBackEventHandler

ASP.NETアプリケーションの起動時にWeb.configファイルを読み込むには

ASP.NETアプリケーションの起動時に設定ファイルを読み込み、システムの初期設定をしたいというケースがあると重います。

設定ファイルを読み込むための、WebConfigurationManager.OpenWebConfigurationメソッドには、引数として設定ファイルの仮想パスが必要です。仮想パスの取得方法として、ASP.NET Web プロジェクトの仮想パスに手順が記載されていますが、アプリケーションの起動時には適用できません。なぜなら、紹介されている方法ではHttpRequestクラスを使用するのですが、アプリケーション起動時には、HttpRequestオブジェクトが使える状態にないからです。

そこで、代わりに使用するのが、HttpRuntimeクラスです。このクラスの、AppDomainVirtualPathプロパティから、アプリケーションの仮想パスを取得できるので、あとはファイル名を結合するだけです。結合には、VirtualPathUtilityクラスを使うとベターでしょう。

var path = VirtualPathUtility.Combine(HttpRuntime.AppDomainVirtualPath,
                                      "Web.config");
var conf = WebConfigurationManager.OpenWebConfiguration(path);

仮想パスをいい加減に扱うと、サーバーへインストールしたら動かなくなることがあります。HttpRuntimeクラスを使い、環境の変化に強いコードを書きましょう。

Javaでクラス図(1クラスだけ!)を書いてみた

グラフを書くためのライブラリの一つに、Graphvizというものがあります。
調べてみたところ、クラス図を書くこともできるようなので、Javaのリフレクションを使ってクラス図を書いてみました。

まだ単体のクラスを出力できるだけですが、関連を出力できるようになるとなかなかおもしろそうです。

参照
Graphviz
UML Diagrams Using Graphviz DOT

C#でアプリケーション設定ファイルを拡張する方法

.NETには標準で設定ファイルを読み込むためのAPIが公開されています。
そのままでも単純なキー=値形式の定義できます。
カスタマイズするには、主に次の3つのクラスを使用します。

• ConfigurationSectionクラス
• ConfigurationElementクラス
• ConfigurationElementCollectionクラス

ConfigurationSectionクラス
カスタマイズした設定項目のルートになるクラスです。

    class NetworkConfigurationSection : ConfigurationSection
    {
        [ConfigurationProperty("LocalHost")]
        public NetworkConfigElement LocalHost
        {
            get { return base["LocalHost"] as NetworkConfigElement; }
            set { base["LocalHost"] = value; }
        }

        [ConfigurationProperty("Networks")]
        public NetworkConfigElementCollection Networks
        {
            get { return base["Networks"] as NetworkConfigElementCollection; }
        }
    }

ConfigurationElementクラス
設定値をもつXMLエレメントに対応するクラスです。

    class NetworkConfigElement : ConfigurationElement
    {
        [ConfigurationProperty("IPAddress")]
        public string IPAddress
        {
            get { return base["IPAddress"] as string; }
            set { base["IPAddress"] = value; }
        }
    }

ConfigurationElementCollectionクラス
複数のConfigurationElementをまとめるクラスです。

    class NetworkConfigElementCollection : ConfigurationElementCollection
    {
        protected override ConfigurationElement CreateNewElement()
        {
            return new NetworkConfigElement();
        }

        protected override object GetElementKey(ConfigurationElement element)
        {
            NetworkConfigElement elm = element as NetworkConfigElement;
            if (null == elm) return null;
            return elm.IPAddress;
        }
    }

ちょっとしたツールを作るのに便利なPythonのcmdモジュールを使うための3ステップ

シンプルなコマンドラインツールが必要なとき、Pythonのcmdモジュールが有力な選択肢になります。ツールを実装するために必要な3ステップを紹介します。

1. cmd.Cmdクラスを継承したクラスを作る
2. do_XXXメソッドを定義する
3. cmdloopメソッドを呼ぶ

cmd.Cmdクラスを継承したクラスを作る

特に言うべきことはありません。普通に継承するだけです。

class HelloCmd(cmd.Cmd):
...

do_XXXメソッドを定義する

メソッド名の"XXX"がコマンドになります。

パラメータを受け取るためのargパラメータがポイントです。

    def do_hello(self, arg):
        print 'hello, ' + str(arg)

cmdloopメソッドを呼ぶ

クラスをインスタンス化し、cmdloopを呼ぶとREPLがスタートします。

終了するにはCtrl-Cで落とします。

>>> HelloCmd().cmdloop()
(Cmd) hello Taro
Hello, Taro
(Cmd) Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/cmd.py", line 130, in cmdloop
    line = raw_input(self.prompt)
KeyboardInterrupt

以下Tips。必須ではありませんが、知っておくと便利です。

Google GuiceのBest Practicesを訳してみた - Guiceがインスタンス化するクラスのコンストラクタはできるだけ隠蔽する

Guiceがインスタンス化するクラスのコンストラクタはできるだけ隠蔽する
次のシンプルなインターフェイスについて考える。

public interface DataReader {
 
  Data readData(DataSource dataSource);
}

一般的には、次のようなpublicクラスで実装することだろう。

public class DatabaseDataReader implements DataReader {
  
   private final ConnectionManager connectionManager;

   @Inject
   public DatabaseDataReader(
      ConnectionManager connectionManager) {
     this.connectionManager = connectionManager;
   }

   @Override
   public Data readData(DataSource dataSource) {
      // ... read data from the database
      return Data.of(readInData, someMetaData);
   }
}

ちょっと見ただけでは、このコードには何も問題がないようにみえる。不幸なことに、

よく知られたことだが、コンストラクタをpublicにするといいことは何もない。publicコンストラクタは、ソースとともに誤った使用方法を広めてしまう。誤った使用方法には次のようなデメリットがある。

• リファクタリングが困難になる
• インターフェースによる抽象化を破壊する
• ソースとの結びつきを強める

何よりも悪いのは、コンストラクタを直接使用すると、Guiceによるインスタンス化を避けることになる。

正すためには、単純に実装クラスとコンストラクタの両方の可視性を制限すればよい。通常はパッケージプライベートを選択すればよく、次のような効果が得られる。

• クラスを同じパッケージ内のModuleでバインドする
• クラスを対象とする単体テストは、直接インスタンス化する

publicと@Injectはエルフとドワーフのようなものだと覚えておくとよい。彼らは協力することもできるが、独立して存在しているのだ。

参照
Keep constructors on Guice-instantiated classes as hidden as possible.

Google GuiceのBest Practicesを訳してみた - Moduleでは条件分岐を避けよ

Moduleでは条件分岐を避けよ
Moduleに変化する部品をもたせることと、異なった環境で異なった動作をするように定義するのは推奨されない。

public class FooModule {
  private final String fooServer;

  public FooModule() {
    this(null);
  }

  public FooModule(@Nullable String fooServer) {
    this.fooServer = fooServer;
  }

  @Override protected void configure() {
    if (fooServer != null) {
      bind(String.class).annotatedWith(named("fooServer")).toInstance(fooServer);
      bind(FooService.class).to(RemoteFooService.class);
    } else {
      bind(FooService.class).to(InMemoryFooService.class);
    }
  }
}

条件分岐自身にはそれほど問題はない。しかし、設定がテストされていない時に問題は現れる。この例では、InMemoryFooServiceは開発環境で使用され、RemoteFooServiceは本番環境で使用される。しかし、この特定の状況をテストしていないと、RemoteFooServiceが統合されたアプリケーションと動作するかは保証できない。

このことからわかるのは、アプリケーションの設定項目は最小限にすべきだということだ。開発環境と本番環境を別々のModuleへ分割すると、本番コードの全てがテストされているのを証明するのはより容易になる。この例では、FooModuleをRemoteFooModuleとInMemoryFooModuleへ分割する。これはまた、製品版のクラスがテストコードに依存しなくなる効果もある。

参照
Avoid conditional logic in modules