SSL化しました。
ボタン一つでちゃんと変わるのすごいですね。
Chromeで「保護されていない通信」とでたり、
SEO的に不利になったりするのでSSL化は必須の時代かもしれません。
まぁ別にアフィリエイトとかしてるわけじゃないので、検索順位とかあまり気にしてなかったのですが。
ちなみにHTTPには戻せないらしいので、ご利用は計画的に。
全部の記事見たりしていないので、画面崩れてたりMixed-Contentとかあったらこっそり教えていただければ…。
こんにちは。
11月11日です。
ポッキー食べましたか?
世の中真っ直ぐな食べ物なんてたくさんあるのに、確固たる地位を築いているのはすごいですね。
ちくわ&ちくわぶの日だっていいし、なんならそうめん&スパゲティの日だっていいわけです。
でももうポッキー&プリッツの日です。広まったら勝ちです。強い。
さて、今日はASP.NETのお話。
.NET Coreでもできるかもしれないけど、とりあえず.NET Frameworkということで。
VisualStudioで「ASP.NET Webアプリケーション(.NET Framework)」のプロジェクトを作成すると、
自動的にこんなRouteConfig.csが作成されます。
public class RouteConfig { public static void RegisterRoutes(RouteCollection routes) { routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); routes.MapRoute( name: "Default", url: "{controller}/{action}/{id}", defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional } ); } }
で、Controllerを作ってあげてlocalhostにアクセスすると(書くの面倒なので、ポート番号は脳内で補完していただくということで)、
デフォルトのルーティング設定が読み込まれて無事にHomeControllerのIndexメソッドが呼ばれるわけですね。
public class HomeController : Controller { public ActionResult Index() { return Content("Index"); } }
次にHomeController にメソッドを追加して、localhost/Home/Hoge/にアクセスしてみると、
今度はHomerControllerのHogeメソッドが呼ばれますね。
public class HomeController : Controller { public ActionResult Index() { return Content("Index"); } public ActionResult Hoge() { return Content("Hoge"); } }
そんな場面あるかい!って言われてしまったら終了なのですが、
URLのルールを変えられないなんてことは稼働中のサービスとかだとあるんですよ。
え、ない?まぁまぁそう言わず…。
とりあえずMapRouteに引数でパラメタって設定できないのかなとか見てみると、
制約をつける「constraints」と名前空間を指定する「namespace」しかありませんでした。そりゃそうか。
とりあえず、他にもパラメタはあるだろってことは完全に無視してこんなルーティングを追加してみます。
routes.MapRoute( name: "Hoge", url: "?action=Hoge", defaults: new { controller = "Home", action = "Hoge" } );
はい、だめでした。
いやそもそも「defaults」って書いてあるくらいなんだから、
ルーティング設定なんて追加しなくてもパラメタに「controller」と「action」を指定して、
localhost?controller=Home&action=Hogeとかにアクセスしてあげれば…。
当たり前ですが、パラメタとは別管理です。
とりあえずActionが実行される前になにかの値を差し替えてしまえばいけそうなので、
OnActionExecutingをoverrideして、ActionExecutingContextの中身を覗いてみると…
「RouteData」というのが多分ルーティングの設定でしょう。
ということは、こんな感じで書けば。
protected override void OnActionExecuting(ActionExecutingContext filterContext) { var parameter = filterContext.HttpContext.Request.Params; if (parameter.AllKeys.Contains("action")) { filterContext.RouteData.Values["action"] = parameter["action"]; } base.OnActionExecuting(filterContext); }
だめでした。
ExecutingってことはもうActionがExcuteされてるんですかね。
じゃあこれならどうだ。
protected override IAsyncResult BeginExecute(RequestContext requestContext, AsyncCallback callback, object state) { var parameter = requestContext.HttpContext.Request.Params; if (parameter.AllKeys.Contains("action")) { requestContext.RouteData.Values["action"] = parameter["action"]; } return base.BeginExecute(requestContext, callback, state); }
やったー。
BeginExecuteでRouteDataを差し替えてあげれば、Actionは自分で決められるようです。
他にもっと簡単な方法はあるんでしょうか?
誰か教えてくださいまし。
こんにちは。
秋ですね。
ようやく暑さも収まりましたが、体調が安定しません…。
なんだか謎掛けみたいなタイトルですが、
変な罠に引っかかりそうになったので備忘録。
nullチェックするようなロジックを書くべきではないとかいう話はまぁちょいちょいありますが、
個人的にはnull自体はそんなに嫌いではないです。
いやべつにNullableとかOptionalを否定する気はないですけど。
null条件演算子とかnull合体演算子とかもありますしね。
で、まぁこういうコードよく書きますよね。
var hoge = GetHoge(); if (hoge != null) { hoge.Fuga(); }
このコードでFugaの呼び出しの際にhogeがnullでNullReferenceExceptionが発生するのはどんなときでしょう?
なんかJSのクイズでたまに見る次のコードで「false」がアラートされるaを答えなさいみたいな感じがありますが。
if (a === a) { alert("true"); } else { alert("false"); }
正解はHogeの「==」「!=」を演算子オーバーロードをミスって書いたときです。
ちなみにJSの方の答えは「NaN」ですね。
演算子オーバーロードについては前に記事を書きましたので詳しくはこちらをどうぞ。
shironeko.hateblo.jp
たとえばプロパティを一つだけ持つクラスの場合、
こんな感じで演算子オーバーロードを書きたいですよね。
class Hoge { public int Piyo { get; } public Hoge(int piyo) { this.Piyo = piyo; } public static bool operator ==(Hoge a, Hoge b) { return a.Piyo == b.Piyo; } public static bool operator !=(Hoge a, Hoge b) { return a.Piyo != b.Piyo; } }
が、これをnullと比較すると第二引数にnullが入ってきて死ぬわけです。
(演算子オーバーロードは左右を意識するので、null == ~って書くと第一引数側で死にます)
public static bool operator ==(Hoge a, Hoge b) { if (a == null && b == null) { return true; } else if (a != null && b != null) { return a.Piyo == b.Piyo; } else { return false; } } public static bool operator !=(Hoge a, Hoge b) { return !(a == b); }
でまぁこんな感じかなと思って書くと、再帰になってStackOverflowで死ぬわけです。
というわけでこうですね。
public static bool operator ==(Hoge a, Hoge b) { if (a as object == null && b as object == null) { return true; } else if (a as object != null && b as object != null) { return a.Piyo == b.Piyo; } else { return false; } } public static bool operator !=(Hoge a, Hoge b) { return !(a == b); }
この辺の書き方を間違えたりすると最初の例のようにnullチェックは通るのに実態はnullでしたみたいなことになるんです。
親クラスで演算子オーバーロードしてたりするとより沼にハマりやすくなります。
しれっと順番を意識するのでとか書いたのですが、
二項演算子のオーバーロードでは片側が自分の型であればもう片側は別の型でも問題ありません。
ということはですよ。
こんなふうに書いたらどうなるのっていう疑問がわきます。
class Hoge { public static bool operator ==(Fuga a, Hoge b) { (略) } public static bool operator !=(Fuga a, Hoge b) { (略) } } class Fuga { public static bool operator ==(Fuga a, Hoge b) { (略) } public static bool operator !=(Fuga a, Hoge b) { (略) } }
結論としてはコンパイル通りませんでした。なんて普通なオチ…。