長年使っていたアクセス解析CGIを手放し、GoogleさんのAnaliyticsへ乗り換えることにしました。なんといいますか、使いこなすのが少し大変そうな印象をうけました。多機能故、項目が散乱していて何が何やら、ってなってしまいます。以前使用していたアクセス解析はOn The Windさんとこのものなのですが、最近私の自前カウンタは回るのにログに残っていないとかいう状態が出てきまして。手当たり次第クッキー発行して重複カウントしないようにしてるんかな?とか思ったりしましたが、まぁそろそろ違うの使ってみよう、とかわけのわからない決意により乗り換えることにしました。そこで、以前GoogleのAnalyticsというのを見かけ、あーGoogleさんってアクセス解析サービスまで始めたんか、と思っていたのを思い出し、Googleさんにしました。
ブログはブログでGoogleの傘下であるBloggerですし、Googleさんの技術にまみれていく自分がいます。向かうところ敵なしなんでしょうかね、Googleさんは。
ところで、Blogの記事に変更を加えようと思いつつ(昨日の記事のことなんですが)、まぁコメント欄から追記すればいいや、と思ってコメントを使いました。久しぶりに。そしたらなんだか動作がおかしい。ブログテンプレートがおかしかったみたいです。Bloggerのヘルプを見ながらクラシック版のコメント機能を使うようにしたら、投稿できるようになりました。以前のバージョンからbeta版、そして今のバージョンに移るまでのどこかの段階で変なことになっていたのかも知れません。
時々他のブログツールに浮気心が出てしまうのですが、Bloggerがどのように変化していくのかが少し気になるので、切り替えの踏ん切りが着かず終いのままだったりします。
Showing posts with label UpdateHistory. Show all posts
Showing posts with label UpdateHistory. Show all posts
Friday, December 22, 2006
Thursday, December 21, 2006
Homepage::Update - scriptとnoscript
何気なく、携帯のOperaで私のWebサイトを閲覧してみたら、JavaScriptが全然働いていませんでした。 Operaだから動くやろーと思ったらそうでもありませんでした。
だもんで、JavaScriptを使ってコンテキストメニューを実現している箇所なんかは、リンク先に飛べなくなってしまうわけでして。それは困る(かもしれない)ので、noscriptタグを駆使してみました。noscriptの時にはliタグでリンクを表示するのはもちろん、JavaScriptが使えないとなると左サイドの装飾が表示されないので、デフォルトで殆どの文字のtext-alignをleftにします。そして、JavaScriptでこのtext-alignをrightに変更することで(他にも要素のクラス名を切り替えたりしていますが)、JavaScriptが使える環境では私の想定しているレイアウトへ復元させるようにしました。JavaScriptをOnにしているときとOffにしているときとでレイアウトが切り替わっています。ちょっとオモロイとか思いました。
だもんで、JavaScriptを使ってコンテキストメニューを実現している箇所なんかは、リンク先に飛べなくなってしまうわけでして。それは困る(かもしれない)ので、noscriptタグを駆使してみました。noscriptの時にはliタグでリンクを表示するのはもちろん、JavaScriptが使えないとなると左サイドの装飾が表示されないので、デフォルトで殆どの文字のtext-alignをleftにします。そして、JavaScriptでこのtext-alignをrightに変更することで(他にも要素のクラス名を切り替えたりしていますが)、JavaScriptが使える環境では私の想定しているレイアウトへ復元させるようにしました。JavaScriptをOnにしているときとOffにしているときとでレイアウトが切り替わっています。ちょっとオモロイとか思いました。
Saturday, December 09, 2006
Homepage::Update - 久しぶりのリニューアル
そろそろ飽きてきたり、DynamicHTMLを覚えたり、デザインのことを少し勉強したりと、諸事情によりトップページをリニューアルしました。今回は、画像を使わずにどんなデザインで表現できるか?というのをテーマにしてみました。矩形は簡単に表現できますが、斜めのラインや楕円、三角形などは表現できませんね...何か上手いやり方が在るのかも知れませんが。
トップページ上に情報をモリモリ書きたくなかったので、どこがポイントやな?って話になりますが、左サイドの装飾と、左クリックによるポップアップメニュー、そしてそれらにかけられる影のエフェクトでしょうか。プログラム的には、裏でクラスの継承やらをちょっといい感じに自前で実装してたりします。サブクラスのコンストラクタ内で
とやれば、スーパークラスのコンストラクタが呼ばれるようにしています。継承するたびに、各スーパークラスのコンストラクタを保存していき、_superで正しいコンストラクタを呼び出せるようにしないといけない箇所がちょっと大変でしたが。
つまり、クラスAのスーパークラスがBで、BのスーパークラスがCだとしておきますと。
として置き、B.prototype.initialize内で
を呼ぶとします。Bを継承してAを定義したときに、
として、A.prototype.initialize内で
を呼びます。B.prototype.initialize内でもthis._super()を呼んでいるわけですが、この_superはA.prototype._superの事になってしまっているので、再びB.prototype.initializeを呼んでしまい...無限ループになります。
これを回避するために、FunctionクラスのtoStringメソッドでソースへ落とし込み、_super()を_super0()というように重複しないように書き換えます。もちろん、B.prototype["_super"]にクラスCのコンストラクタを代入するのではなく、
としてやります。この__INHERITANCE_NUMBERは継承回数-1としておき、継承を行うたびにカウントアップしていけば、_superが書き換えられずにきちんと保存されているように見えます。
ソースコードへ落とし込んだ後、Firefoxではeval()してやれば関数オブジェクトを返してくれたのですが、IEでは何も返してくれません。だもんで、無名関数を定義して、そのなかで上記のthis._super0の中身を実行するようなevalを書いてやらなければなりませんでした。この無名関数を、B.prototype["_super0"]に代入してやればOKです。
スーパークラスが何かが分かっているんだから、いちいち_superを自動で定義してやらなくても、手で書けばいいじゃないか、という話になるのですが、こっちの方がエレガントかなぁとか思いまして(笑)変数(名)がクラス(名)のように扱われるので、
とやれば、C言語でいうtypedefが簡単に出来てしまいます。ので、スーパークラスのコンストラクタ呼び出しも、上記のようにスーパークラスに別名をつけるような処理を行っておけば、長いクラス名でも手で打つのは全然面倒ではありません。
まぁ、あくまで自己満足と勉強のためにわざわざ、スーパークラスへのアクセスキーワードを定義したりしているわけです。JScriptだったらsuperキーワードが定義されていたような気も。
ちなみに現在は、スーパークラスのコンストラクタ呼び出し以外にも、スーパークラスのメソッド呼び出しも可能にしたいとか思っておりまして。overrideしたメソッドから、overrideされた元々のメソッドを呼びたい時に、Perlみたく、$obj->SUPER::method()と書きたいわけでして。Firefoxだったら動くのにIEだと動かない!という状況に再び遭遇したので、もう少しこの問題と格闘しそうです。
トップページ上に情報をモリモリ書きたくなかったので、どこがポイントやな?って話になりますが、左サイドの装飾と、左クリックによるポップアップメニュー、そしてそれらにかけられる影のエフェクトでしょうか。プログラム的には、裏でクラスの継承やらをちょっといい感じに自前で実装してたりします。サブクラスのコンストラクタ内で
this._super();
とやれば、スーパークラスのコンストラクタが呼ばれるようにしています。継承するたびに、各スーパークラスのコンストラクタを保存していき、_superで正しいコンストラクタを呼び出せるようにしないといけない箇所がちょっと大変でしたが。
つまり、クラスAのスーパークラスがBで、BのスーパークラスがCだとしておきますと。
// prototype.jsのClass.create()使っているのでinitialize
B.prototype["_super"] = C.prototype.initialize;
として置き、B.prototype.initialize内で
this._super();
を呼ぶとします。Bを継承してAを定義したときに、
A.prototype["_super"] = B.prototype.initialize
として、A.prototype.initialize内で
this._super(); // これはB.prototype.initializeだが...
を呼びます。B.prototype.initialize内でもthis._super()を呼んでいるわけですが、この_superはA.prototype._superの事になってしまっているので、再びB.prototype.initializeを呼んでしまい...無限ループになります。
これを回避するために、FunctionクラスのtoStringメソッドでソースへ落とし込み、_super()を_super0()というように重複しないように書き換えます。もちろん、B.prototype["_super"]にクラスCのコンストラクタを代入するのではなく、
B.prototype["_super"+B.__INHERITANCE_NUMBER] = C.prototype.initialize;
// B.__INHERITANCE_NUMBER = 0
としてやります。この__INHERITANCE_NUMBERは継承回数-1としておき、継承を行うたびにカウントアップしていけば、_superが書き換えられずにきちんと保存されているように見えます。
ソースコードへ落とし込んだ後、Firefoxではeval()してやれば関数オブジェクトを返してくれたのですが、IEでは何も返してくれません。だもんで、無名関数を定義して、そのなかで上記のthis._super0の中身を実行するようなevalを書いてやらなければなりませんでした。この無名関数を、B.prototype["_super0"]に代入してやればOKです。
スーパークラスが何かが分かっているんだから、いちいち_superを自動で定義してやらなくても、手で書けばいいじゃないか、という話になるのですが、こっちの方がエレガントかなぁとか思いまして(笑)変数(名)がクラス(名)のように扱われるので、
var D = C;
とやれば、C言語でいうtypedefが簡単に出来てしまいます。ので、スーパークラスのコンストラクタ呼び出しも、上記のようにスーパークラスに別名をつけるような処理を行っておけば、長いクラス名でも手で打つのは全然面倒ではありません。
まぁ、あくまで自己満足と勉強のためにわざわざ、スーパークラスへのアクセスキーワードを定義したりしているわけです。JScriptだったらsuperキーワードが定義されていたような気も。
ちなみに現在は、スーパークラスのコンストラクタ呼び出し以外にも、スーパークラスのメソッド呼び出しも可能にしたいとか思っておりまして。overrideしたメソッドから、overrideされた元々のメソッドを呼びたい時に、Perlみたく、$obj->SUPER::method()と書きたいわけでして。Firefoxだったら動くのにIEだと動かない!という状況に再び遭遇したので、もう少しこの問題と格闘しそうです。
Subscribe to:
Posts (Atom)