ニコカレ フォローアップ編


部屋の電気が突然つかなくなって、蛍光灯の交換に3,000円の出費…(´A`)


で、公開したニコカレに対するフィードバックに関してです。


ニコカレでデータを登録する日の選択については、Calendarコントロールで指定するようにしていますが。
これが、日曜始まりの方が良いんじゃないの?、っという意見がありました(゚∀゚)


これ、個人的な趣味で、FirstDayOfWeekをMondayにしてるんですよねぇ。
ニコカレだけでなくて、温度監視システムとか他のシステムでも、カレンダーを月曜始まりにしていたり。


自分は、月曜始まりが生活の基本になっています(・∀・)
使っている手帳もリベルプラスですし。


システム手帳は月曜始まりのも多いですが、本当は卓上カレンダーも月曜始まりのものが欲しいんですよね。
卓上カレンダーはわざわざ買うことも少ないというか、年末に貰うものを使っていたりするので、普通は日曜始まりになっていますが。


世間一般的には日曜始まりかもしれないですけど、自分は月曜始まりが好きなんですよ(・∀・)
ついでに言うと、四勤二休の人用に六日単位のカレンダーなんてのもあっていいんじゃないかと思ったり。


閑話休題


で、本気で対応を考えるなら、ユーザ単位で月曜始まりか日曜始まりかを選択できるように、パーソナライズすることになるかと思います。
ASP.NET 2.0でパーソナライゼーションをする場合、通常だとProfileオブジェクトを使用しますが。


ただ、Profileだとちょっと気になるところもあったりして。


ニコカレでは他のアプリケーションとアカウント情報を共有できるように、個別のMembershipデータベースは持っていません。
Membership ProviderのapplicationNameに同じものを指定することにより、他のアプリケーションとMembershipデータベースを共有するように設定しています。


で、Profileに独自のプロパティを定義する場合、Web.configのに定義を記述するわけですが。
複数アプリケーションで同じMembershipデータベースを共有する場合、この設定も共通にしておかないとProfile情報が壊れちゃうんですよね…(´・ω・`)
壊れちゃうっていうのは、aspnet_ProfileへのProfile情報の保存方法の問題で、アプリケーション毎に固有のプロパティを持たせるような事ができないという意味です。


っというわけで、後からの拡張を考えたりする場合、複数アプリケーションで同じMembershipデータベースを使う場合にはProfileは使いづらいな〜等と思うわけです。
一般的にはあんまりこういう事はしないんですかね?


で、共通認証システムに、パーソナライズの独自機構も作りこまないと駄目かな〜(´ω`)