2006年8月 Archive

Atlasをいろいろ試していたところ、動作は全く問題ないのですがひとつだけ気になるところが．．．
サンプルコードを見ると、
<Atlas:ScriptManager ID="ScriptManager1" runat="server" EnablePartialRendering=true />
のように書かれているコードですが、私の環境でコントロールを貼り付けると、
<cc1:ScriptManager ID="ScriptManager1" runat="server" EnablePartialRendering=true />
のように、タグ名が変わってしまっていました。

調べてみたところ、どうやらこのタグはページ内で統一していれば、なんでもいいようです。
定義するところは、
<%@ Register Assembly="Microsoft.Web.Atlas" Namespace="Microsoft.Web.UI" TagPrefix="cc1" %>
のTagPrefixの部分を変えてやればいいようです。つまり、
<%@ Register Assembly="Microsoft.Web.Atlas" Namespace="Microsoft.Web.UI" TagPrefix="Atlas" %>
とするだけで、サンプルのような書き方ができるようになります。

参考
TagPrefixInfo.TagPrefix プロパティ

Continue reading

Atlas（コードネーム）とは、次期VisualStudioに含まれると予想されるAjaxのフレームワークを意味します。

[ASP.NET "Atlas" 概要]を読んでいただければ思想は理解できるのではないかと思います。
要するにAjaxを楽に開発しちゃおうということなんですが、実際にサンプルを見てみるまではまゆつばものでした。

あれこれ考える前に、こちらのサンプルをご覧ください。
Microsoft "Atlas" Control Toolkit

Ajaxが登場したとき、開発者でない人もその操作性に驚いたものですが、WEB開発を生業としている人は、「ああ、またJavaScriptかあ」と思った人も多いんじゃないでしょうか。
JavaScriptは情報の受信専門だった、WEBの世界にクライアント側の操作という概念を生んだということでは大きな存在なのですが、一方で開発の面倒くささ（デバッグ等）のために忌み嫌われてきた部分があります。実際、私も仕事ではやむを得ず使いますが、大嫌いです。
そのため、Ajaxが出たときも、「すごいけど、面倒だなあ」と考えていました。

しかし、このサンプル、ソースを見ると考えが一変します。
もう例える言葉が「すごい」しか出てきませんでした。
動きがWEBアプリケーションと差が無くなってきているのに、通常のコントロールと同様のコーディング量なのです。
本日の段階で21個のコントロールも、これからどんどん増えていくようです。
これほどの衝撃を受けたのは、はじめてインターネットを見たとき以降かもしれません。

当ブログも、これからAtlasを追っていこうと思います。

Button.OnClientClickプロパティを利用したJavascriptの実行

Button.OnClientClick プロパティ

この機能もASP.NET2.0で追加されたものです。
ASP.NET1.1までは、
Button.Attributes("OnClick") = "javascript:*******";
のように記述していたものが、
Button.OnClientClick = "*******";
のように短縮することができます。

例えば、
Button.OnClientClick = "return confirm('****してもよろしいですか？');";
のように書けば、確認ダイアログを表示し、OKボタンが押されたときのみ Button.OnClickイベントが実行されるようになります。

共通的なDataAccessクラスを作成していたところ、エラーが発生したので公開します。

エラー内容
　着信の表形式のデータ ストリーム (TDS) リモート プロシージャ コール (RPC) プロトコル ストリームが不適切です。パラメータ 8 ("@HOGE"): データ型 0xE7 に、無効なデータ長またはメタデータ長が指定されています。

該当箇所のソースコードは以下のとおり

    DbParameter dataParamArray = new DbParameter();

    dataParamArray.ParameterName = "@HOGE";

    dataParamArray.Direction = ParameterDirection.Input;

    dataParamArray.Size = 8000;

    dataParamArray.Value = "TEST";

プロパティをいろいろいじって調べてみると、どうやら dataParamArray.Size に大きな数値を入れると異常終了することが判明しました。
そこでMSDNで調べてみたところ、dataParamArray.Size や dataParamArray.Type は特に設定する必要は無く、dataParamArray.Value によって自動的に判別されるとのこと。
実際、dataParamArray.Sizeを削除したところ、正常に動作しました。

以前、SQL文を実行してSQLServer上のテーブル一覧を取得する方法を紹介しましたが、今回はスキーマコレクションから取得する方法です。

参考
SqlConnection.GetSchema メソッド
GetSchema メソッドの使用

参考の例だとSqlConnectionを使っていますが、.NET Framework version 2.0なら DbConnectionを使うこともできます。
実際に他のデータベースで試したことはないですが、テーブル情報取得のSQL文はデータベースによって大きく異なるため、結構使えるかもしれません。

マスターページの仕組みは一貫したデザインを実現したい場合、大変便利な方法ですが、コンテンツページからマスターページのデータにアクセスするのはとても面倒です。
多くの人が Master.FindControl("コントロール名")のように記述していることと思います。
この場合、コントロール名が変更になったときの修正漏れが心配になります。

ところが、@MasterTypeディレクティブを追加することで、プロパティ経由のデータアクセスが可能になります。
簡単に説明すると、コンテンツページ(*.aspx)に、<%@ MasterType virtualPath="~/MasterPage.master"%>のような１行を加えるだけです。
（MasterPage.masterの部分は各自の環境に合わせて変更してください）
あとはマスターページにプロパティを追加するだけです。

例えばLabelであれば、

public string LabelText

{

    get { return Label1.Text; }

    set { Label1.Text = value; }

}

参考
プログラムによる ASP.NET マスター ページの操作

@IT:［ASP.NET］コンテンツ・ページからマスター・ページの情報に簡単にアクセスするには？［2.0のみ、C#、VB］

アプリケーション起動中、常にファイル監視をする要件があったとします。
具体的に言うと、あるファイルを常に監視し、ファイルが変更されたときに再読み込みをする等のイベントを処理させます。
実装例としては、自前で用意した環境ファイルのデータを保持するといったようなものが考えられると思います。

ファイルの監視方法ですが、FileSystemWatcherで監視するファイルを設定し、FileSystemEventHandlerでイベントハンドリングを行えばよさそうです。
こういう仕組みが備わっているのが.NETの良さですね～

FileSystemWatcher watcher = new FileSystemWatcher(ファイルパス, ファイル名);
watcher.Changed += new FileSystemEventHandler(処理したいメソッド名);

のようにすればOKです。
常時監視ということなので、監視モジュールが常にメモリにロードされている必要があります。
常時ロードとなると、ASP.NETの場合、Application_Startに記述してしまえばいいのですが、そのロジックをWindowsアプリでも汎用的に使うことはできません。

そこで、ASP.NETでも常にメモリにロードされているということで、Singleton実装にしてみました。
Singletonのそもそもの目的は、アプリケーション内で唯一存在するオブジェクトを作成するためなのですが、唯一存在させるためにインスタンスをstaticで保持しています。
そのため、Singletonのコンストラクタで上記の監視ロジックを入れておけば、常にメモリに存在することとなり、どのプログラムを実行していてもイベントが発生します。
問題点は、Singletonなので複数のファイルを監視できないことですが、そのような場合はGetInstanceの仕組みを変えてあげることで対処できそうです。

HttpModuleでゴリゴリやってたら、HttpModule内でポストバックの判定が必要になってしまいました。
ところが、IsPostBack()メソッドってPageにしか存在しないため使えないんですね。

仕方がないので、Page.IsPostBack()と同等の機能を実装することにします。
ポストバックとそうでないときで違うところと言えばViewStateの扱いなので、このあたりを実装すると良さそうです。
サンプルコード(C#)は下記のとおりです。
「this.httpApp」の部分は、各自の環境に合わせたHttpApplicationオブジェクトを指定してください。

#region ポストバック判定処理
/// 

/// ポストバックかどうか判定する。
/// 
/// ポストバック時は true、ポストバックではないときは falseを返します。
/// 
/// HttpModule では IsPostBack を実装していないため、「__VIEWSTATE」が Request.Params に存在するかでチェックしています。
/// 
private bool IsPostBack()
{
    try
    {
        return (this.httpApp.Context.Request.Params["__VIEWSTATE"] != null);
    }
    catch
    {
        return false;
    }
}
#endregion

C#では（というかほとんどのオブジェクト指向言語では）、オブジェクトのCloneを行うと参照のみがコピー（シャローコピー）されます。
シャローコピーのときは、値を変更するとコピー元のデータも変更されてしまうので、オブジェクトのバックアップを取りたいときは値そのものをコピー（ディープコピー、ディープクローン）するように実装しなければなりません。

一番簡単な方法はオブジェクトをシリアライズし、それを別オブジェクトにデシリアライズすることです。
汎用的に使えるのですが、オブジェクトがシリアライズ化できる必要があります。
シリアライズ化対応でない場合、そのオブジェクトごとに値の詰め替えを実装しなければなりません。

以下、シリアライズを使用したディープコピーのサンプルです。

/// <summary>

/// オブジェクトをディープコピーする。

/// </summary>

/// <param name="source">コピー元オブジェクトを指定します。</param>

/// <returns>コピー先オブジェクトを返します。</returns>

/// <remarks>このメソッドを使用するには、対象クラスが Serializable できることが前提となります。</remarks>

public static object DeepClone(object source)

{

    object target = null;

    using (MemoryStream stream = new MemoryStream())

    {

        // コピー元オブジェクトをシリアライズします。

        BinaryFormatter formatter = new BinaryFormatter();

        formatter.Serialize(stream, source);

        stream.Position = 0;


        // シリアライズデータをコピー先オブジェクトにデシリアライズします。

        target = formatter.Deserialize(stream);

    }

    return target;

}