2005年8月29日月曜日

PHPのフレームワーク



某掲示板を眺めていたらPradoというPHP用のフレームワークが紹介されていた。ぶっちゃけ初めて知ったわけですが・・・。

まー、簡単に言うとmojaviがStruts系ならこちらはJSF系とか。（JSF系はあまりいじっていないので正直よくわからない＾＾；）

しかし、最近PHPがJavaの真似をして進化（？）しているのを見てると素直にJava使えば良いんじゃないの？って気がしなくも無い今日この頃。もちろん動作させる環境っていう点ではPHPの方が圧倒的に敷居が低いという背景もあるわけで一概にJavaが良いとは言い切れないけど、目指すところが一緒であるとベースがしっかりしたJavaの方が運用するシステムにとっても良いんじゃないかと思う。また、実体験からくる話ではないけどPHPは規模が大きくなると設計云々ではなくエンジンの問題で非常に重くなると聞いているので尚更かな。

ぶっちゃけ以前にStrutsを使ったものを作って以来Javaが嫌いだったけど、その理由の一つにデザインとロジックを分けてる割にはデザインがしにくかった事がある。これはテンプレートエンジンに何を使うかによって細かく左右される問題だけど、テンプレートエンジンというものを使ってビューとロジックを分ける時点でカスタムタグを使ったり独自の構文をもったファイルをビューとして使うので既存のHTMLエディタではビジュアルな感じでエディット出来いわけで、そうなると後からデザイナがちょこちょことデザインを手直しするわけにはいかなくなる。これじゃ本末転倒だしその為に発生する面倒なクラス作成作業とかを考えるともっと手軽にいきたいと思ってしまって「嫌い」になったわけ。

ただ、最近状況が変わってきてDreamweaverとかがカスタムタグに"一応"対応してきたとか、他の環境でも結局Javaをお手本にしてるので大差無いとかそんな理由でどーでもよくなってきたのも事実。それならつぶしが利くJavaで良いんじゃないかなってのが最近の感想。

なんかこのWebアプリの世界っていろいろ試行錯誤して徐々に前に進んでる感があるんだけど、車輪の再発明的な感触がどうしてもぬぐえない。まぁGUIのアプリを作るって時も色々問題があったわけで完全に綺麗な方向にはどうしてもいけないってのが結論なんだろうか。それなら泥臭い作業はスクリプトで自動化してさっさと作って次の仕事に取り掛かる。言ってみればやっつけみたいな状態にいくわけだけど、これだと張り合いが無いしねぇ。（まぁ実際そういうスタンスのフレームワークもあり、作業効率は結構良いらしいです）

何気にPradoに関しては何も触れてないけど、、、まー気にしないようにｗ

そういや書いていて思い出したんだけどXSLTってどこ行っちゃったんだろう。

あの辺が現状を打破するのに最適と信じてASP上で簡単なエンジンを作った記憶があるけど、、、懐かしいなぁ




投稿者 時刻: 0 件のコメント:
ラベル:

2005年8月23日火曜日

Amazonの1clickって・・・



ギフト券使えないのね・・・orz

ブックカバープレゼントとかやってるんでカート入れてうっかり1clickをポチっとやってしまったら・・・ギフトナンバー入れる前に確定してしまい　糸冬

きっちりカバー代を支払うことに・・・orz




投稿者 時刻: 0 件のコメント:
ラベル:

2005年8月18日木曜日

FCS(flashcom)上での共有オブジェクトの扱い



サーバサイド(FCS)で共有メモリを作り、そこにプロパティをセットする。そしてそれをクライアントから見るという形の使い方をしたかったけど、どうしても値が保存されず意図した動きにならない。

Client.prototype.Hoge = function()
{
var test_so = SharedObject.get("test");
trace("version : " + test_so.version);

test_so.lock();

test_so.setProperty("test", "hogehoge");
trace("version : " + test_so.version);

trace("test : " + test_so.getProperty("test"));

test_so.unlock();
trace("version : " + test_so.version);

test_so.close();

var test2_so = SharedObject.get("test");
trace("version : " + test2_so.version);
trace("test : " + test2_so.getProperty("test"));
test2_so.close();
}

このコードをクライアントFlashからつついて実行すると


version : 0

version : 0

test : hogehoge

version : 1

version : 0

test : null


こんな感じになります。test2_soのtestプロパティには「hogehoge」が保存されてくれなくて困っていたのですが、バージョンをとってみて気付いたのは値を変更した場合に１になってるバージョンが再度取得してみると０に戻っている。つまり保存がされていないわけです。

で、結論から行くと


test_so.close();


がガンだったりします。これを消すと


version : 0

version : 0

test : hogehoge

version : 1

version : 1

test : hogehoge


ばっちり(゜∀゜)

新規に作成される場合の共有オブジェクトはクローズすると共有メモリそのものがパージされてしまうらしい。本来このメソッドの挙動は共有オブジェクトへのコネクションをはるものという事を考えるとバグだと思うのですが・・・。ちなみに後の


test2_so.close();


では消えません。こっちは期待通りの挙動です。

一応解決したものの何か複雑なものがありますな・・・。




投稿者 時刻: 0 件のコメント:
ラベル:

2005年8月15日月曜日

Flash Remoting系のもの簡単にまとめ








投稿者 時刻: 0 件のコメント:
ラベル:
登録: 投稿 (Atom)