<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>djakarta-trap</title>
	<atom:link href="http://djakarta-trap.net/blog/feed/" rel="self" type="application/rss+xml" />
	<link>http://djakarta-trap.net/blog</link>
	<description>短期記憶がニワトリ並みな僕の、覚え書き。</description>
	<lastBuildDate>Tue, 01 Feb 2011 17:23:28 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>OOPについて説明してみる。 haXeで。</title>
		<link>http://djakarta-trap.net/blog/2011/02/oop_01/</link>
		<comments>http://djakarta-trap.net/blog/2011/02/oop_01/#comments</comments>
		<pubDate>Tue, 01 Feb 2011 16:45:35 +0000</pubDate>
		<dc:creator>djakarta-trap</dc:creator>
				<category><![CDATA[OOP]]></category>

		<guid isPermaLink="false">http://djakarta-trap.net/blog/?p=332</guid>
		<description><![CDATA[ある概念を自分が理解できたかどうかは、人に説明して、その概念を理解してもらえたかで測れる。 っつー事で、内部の人たち向けに「OOPってオイシイの？」について説明してみた時の資料を晒します。 ソースみせながら喋る前提のスライドなので、文字面だけ読むと意味不明です。 が、最後にサンプルファイルも用意してるので、それを弄ってみれば解ってもらえるかと思います。 嘘、大げさ、紛らわしい等々は、JAROの前に@djakarta_trapまで。 補足 サンプルファイルとして、今回はhaXeを使ったソースを用意してあります。 コンパイルするには、FlashDevelop を用意してもらわねばなりません。 ひょっとしたら、同じソースコードから、haXe to AS3, haXe to JS の書き出しを 試してみたい人のお役にも立てるのかもしれません。 そのあたりに興味がある人も、是非に。]]></description>
		<wfw:commentRss>http://djakarta-trap.net/blog/2011/02/oop_01/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CommandExecutorで幸せ家族計画</title>
		<link>http://djakarta-trap.net/blog/2010/06/commandexecutor1/</link>
		<comments>http://djakarta-trap.net/blog/2010/06/commandexecutor1/#comments</comments>
		<pubDate>Mon, 21 Jun 2010 17:13:26 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Progression]]></category>

		<guid isPermaLink="false">http://djakarta-trap.net/blog/?p=286</guid>
		<description><![CDATA[ここ最近、Progression4を使う上でオレオレ・ルールになりつつある事をご紹介。 CommandExecutorを使い倒してアニメーションを色々制御したら、幸せ家族計画できそうだな、の話です。 能書きは要らない、漢は黙ってサンプルファイル。（FlashはCS4版です） 以下、一応覚書として記事書きます。 CommandExecutorとは 名前の如く「コマンドを執り行う」役割のクラスです。 このクラスのインスタンスのメソッドにaddCommand(&#8230;commands)があるんですが、ここで追加されたコマンド達の進行管理をしてるクラス、と思ってもいいんじゃないでしょうか。 このクラスを使って、インスタンスのアニメーションを制御する事を試みてみましょう、ってのが、本題です。 色々な動きをするインスタンスを制御 サンプルファイルのswfを実行してみると、以下の順序でアニメーションが実行されると思います。 青い四角が、左上から右上へ動く。 青い四角が、右上から右下へ動く。 出現したグレーのボタンを押すと、青い四角が左上から右下へ動く。 この青い四角は同一インスタンスで、アニメーションの種類としては２種類です。 ３のアニメは、１と２を同時に実行しています。 このアニメーションを実際に実行させてるのは、IndexScene.asのatSceneInitハンドラ内で、以下のようになってます。 mySP(青い四角)の horizontalExecutor, verticalExecutor がそれぞれ CommandExecutorインスタンスで、 DoExecutorコマンドを使って CommandExecutorインスタンスを実行させてます。 コマンドを使わずにCommandExecutorインスタンスを実行させる場合は、 です。 それぞれ引数にEventインスタンスが渡されてるんですが、ここがポイントとなります。 アニメーションをしてる本人、青い四角のクラス MySprite1.as には、以下のように書いてます。 なんとなく解ってもらえるかと思いますが、MySprite1インスタンス自身が、&#8221;vertical&#8221;, &#8220;horizontal&#8221; というイベントを聴いていて、それぞれのハンドラ内で、CommandExecutorインスタンス.addCommand();しています。 これだけです。 あら便利！ 利点 この方法でアニメーションを実装する利点としては、個人的には以下のことがあると思います。 アニメーションロジックを、アニメーションするクラス自身に書けて、しかも隠蔽できる上に、更にシーン遷移と同期もできる。 アニメーション順番の入れ替えが簡単に。 イベントタイプ名を解りやすく付けられれば、シーンオブジェクトを見ただけでおおよその流れが把握できる という感じでしょうか。 個人的には、１つ目の恩恵がかなり大きいです。 僕の管理感覚では、動く本人に動くロジックが書いてあるのはとてもわかり易いです。 以前はシーンオブジェクトにみっしりアニメーションを書いてて、共通のアニメを他のシーンオブジェクトでも使いたいとなった時は、カスタムコマンド化かコピペをしてたんですけど、前者は管理ファイルが増えるし、コピペは変更が面倒になるしで。。 どのシーンオブジェクトからもアニメーションを１行で簡単に呼び出せるのは、かなり重宝してます。 気をつけるべき点 端的に言うと、複数のアニメーションをこの方法でつける場合、各アニメーション同士が干渉しないかどうかを確認することです。 「アニメーションが干渉する」っていうのは僕の造語なんですが、要は、同時に実行しても、それぞれのアニメーションの結果がキチンと見た目に反映されてる状態であることを確認しというた方がいいよ、って事です。 例えば、サンプルファイルの水平アニメーションをしてる部分を、以下のように書き換えたとします。 垂直方向の座標ゼロの位置に移動するアニメーションにしたのですが、実行結果を見ればわかりますが、グレーのボタンを押したときの見た目の結果に、ゼロ位置へ移動は見て取れません。 当たり前ですがw こういう状況は、アニメーションが複雑になっていくと結構ハマるポイントになってしまうし、アニメのタイミングによってはシーン遷移が終わらないという状況にもなりえるので、気をつけましょう。 ポイントは、同次元（同軸）のアニメーションは、同じCommandExecutorインスタンスに管理させることな気がします。 終わりに んな感じで、アニメの管理にCommandExecutorを使うと便利よー話を、覚書。 こんな便利なクラスは、Progressionの裏で暗躍させておくだけでは勿体無い！ [...]]]></description>
		<wfw:commentRss>http://djakarta-trap.net/blog/2010/06/commandexecutor1/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>JSON + Flash + PHP での注意点</title>
		<link>http://djakarta-trap.net/blog/2009/12/json-flash-php_1/</link>
		<comments>http://djakarta-trap.net/blog/2009/12/json-flash-php_1/#comments</comments>
		<pubDate>Fri, 11 Dec 2009 10:11:46 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Flash]]></category>
		<category><![CDATA[JSON]]></category>
		<category><![CDATA[php]]></category>
		<category><![CDATA[文字コード]]></category>

		<guid isPermaLink="false">http://djakarta-trap.net/blog/?p=264</guid>
		<description><![CDATA[サーバーの設定によっては、POST送信したデータの中に、意図しない「\」(バックスラッシュ)が混入するケースがある。 要因は、php.ini での設定項目、magic_quotes_gpc　パラメーター。 http://jp.php.net/manual/ja/info.configuration.php#ini.magic-quotes-gpc サーバーの処理では、「GPC処理」というものがあるらしい。 端的に言えば、GET,POST,COOKIEのデータが受渡される際に、なんやかんやとデータに対する処理が行われる、と。 その時に、シングルクオート(&#8216;)、ダブルクオート(&#8220;)、バックスラッシュ(\)、NULL(という文字？未確認)には、 すべて自動でバックスラッシュ・エスケープ処理が行われる。　そんな設定がある、と。 いろいろと問題が起こったスクリプトの概要はこんな感じ。 recieveJSON.php ActionScript3 出力は以下。 サーバー側の設定で、GPC処理がOnになっていると、ダブルクオートの直前にバックスラッシュエスケープが 挿入される。それをそのまま　echo で出力すると、上記のようになる、と。 なんでわざわざ、バックスラッシュ・エスケープする必要があるのかよく分からないんですが。 解決方法 1. php.iniの書き換え magic_quotes_gpc = On と書いてある所があるので、それを magic_quotes_gpc = Offにする。 2. php内で頑張る stripcslashesすると、クォートされた文字列を、クォートされてない状態に戻してくれる。 3. swf内で頑張る ダブりを承知で、encodeURIをする。 ダブりというのは、URLVariablesの動的プロパティに値を突っ込んだ段階で、本来はescapeされているのだけど、 そこにさらに、encodeURIをかぶせる、という事。 上記コードのトレース出力は、以下の通り。 myURLVar= com=%257B%2522name%2522%3A%2522%25E5%25AF%258C%25E5%25A3%25AB%25E5%25B1%25B1%2522%2C%2520%2522altitude%2522%3A3776%257D 上記の値をほうを、http://urlencode.net/でデコードしてみると、 %7B%22name%22:%22%E5%AF%8C%E5%A3%AB%E5%B1%B1%22,%20%22altitude%22:3776%7D となる。 ようは、「%」をさらにエンコードして、「%25」にしてあるだけです。 これでなぜ、php再度のGPC処理のダブルクオートがエスケープされる処理がなかった事になるのか、 詳細は理解出来てません(汗。 091214 追記 phpから単純に echo すると成功してる風なんですが、実際、php内でjson_decodeが出来ない 状態に陥ってしまうようです。 なので、実質、swf内では何も出来ないって事ですかね・・・。 どの方法でJSONを利用するか magic_quotes_gpc設定をOffると何か他の処理で影響があったりするのでしょうか。 僕にはその知識がないので、なんとも言えませんが、もし問題なければ、この方法が最もいいんじゃないでしょうか。 PHPer, AS3er, [...]]]></description>
		<wfw:commentRss>http://djakarta-trap.net/blog/2009/12/json-flash-php_1/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Progression で MVC的なサムシング (3)</title>
		<link>http://djakarta-trap.net/blog/2009/12/progression-mvc-3/</link>
		<comments>http://djakarta-trap.net/blog/2009/12/progression-mvc-3/#comments</comments>
		<pubDate>Thu, 10 Dec 2009 14:43:07 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[mvc]]></category>
		<category><![CDATA[Progression]]></category>

		<guid isPermaLink="false">http://djakarta-trap.net/blog/?p=257</guid>
		<description><![CDATA[なんか、新たに色々と本を読んでいたら思う所があったので、再び、グチグチとMVCの話を。 結論。 MVCのセットは、「1アプリケーションに1セット」ではない！ SceneObjectは、swfレベルではModel層っぽく、アプリケーションレベルではコントローラー層っぽいヤツとして扱う。 視点をどこにおくかで、MVC構造は変わるらしい。 事の発端は、「WEB+DB vol.53」の&#8221;MVC入門編&#8221;という記事。17ページ目の図4。 MVCの構造自体が、入れ子のようになるのが常なようです。 （挿絵を準備中） 自分の中でも、そうなんじゃないのかなー、とは思いつつ、スタンダードな方法が何なのかは 全く分からない状態だったので、この記事に背中を後押しされた気分です。 swfを作る際に（特に、設計する時に）意識しなきゃいけないのは、 アプリケーションレベルがどの範囲で、自分が作るswfがどのレベルのモノなのかを把握する事 なんでしょうね。 そこを意識して、自分の目線を定めないと、うまい事設計できないのかなー、と。 Progressionの上手い扱い方 提案1 php + データベース + swf (Progression) っていう案件の場合、アプリケーションレベルでのMVCは、 [アプリケーションレベル] Model : データベース Control : swf と php View : swf となると思います。 さらに、入れ子になるようにswf の中にもMVCが存在するわけですが、その際、Progression をどう使って行けば、 上手いこと外部と連携しつつ、swf内の秩序も守って行けるのかを考えた結果が、以下のようなクラス図。 AppModelのprotected static なメンバとして、php と連携すべきデータを保持して、そのサブクラス（MySceneObject）で 適宜phpに送ったり、phpからデータをもらったりする。 Model層としての役割は、AppModelクラスが担当していて、アルゴリズム的な実装はすべてこのクラスに書く。 MySceneObjectは、ルートシーンにaddSceneされるようになっていて、 swf内のコンテンツは、基本的にはMySceneObjectインスタンスのシナリオ通りに動く。 モデル層に変更が必要な場合は、MySceneObjectがスーパークラスのアルゴリズムを利用して 変更を加えていく事になります。 Progressionインスタンスは、swfレベルでのコントローラー層となって、適切なシーンに状態遷移をしてもらう。 ・・・みたいな流れでしょうか。 大雑把にまとめれば、 SceneObject（のサブクラス）は、swfレベルではモデル層と状態保持（ステートパターンのステートクラス？）の役割をして、 [...]]]></description>
		<wfw:commentRss>http://djakarta-trap.net/blog/2009/12/progression-mvc-3/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[CS4]条件つきコンパイルのメモ。</title>
		<link>http://djakarta-trap.net/blog/2009/12/conditional_compile01/</link>
		<comments>http://djakarta-trap.net/blog/2009/12/conditional_compile01/#comments</comments>
		<pubDate>Wed, 02 Dec 2009 11:52:43 +0000</pubDate>
		<dc:creator>djakarta-trap</dc:creator>
				<category><![CDATA[UnitTest]]></category>

		<guid isPermaLink="false">http://djakarta-trap.net/blog/?p=246</guid>
		<description><![CDATA[この記事を読んでいて、「条件つきコンパイル」というキーワードにぶつかったので、メモ。 結論。 条件付きコンパイルで設定した定数で、特定のコードやクラスをコンパイルから除外できるよー。 条件付きコンパイルのやり方 [ファイル]→[パブリッシュ設定]→[Action Script 3.0 設定]　で、「Action Script 3.0 の詳細設定」ウィンドウを開く。 で、コードの中に、コンパイルされたくない部分を、こんな感じで書く。 「ActionScript 3.0 の詳細設定」ウィンドウで設定した定数を true にしてコンパイルして実行すると、 トレースが実行される。 定数を false にしてコンパイルして実行すると、トレースされない。 このやり方、まるっとメソッドを内包して書いてもイケます。 定数が true であると、トレースが実行されます。 さらに。 class のアクセス制御子に書く事もできます。 こうなると、クラスごとコンパイルされません。 アサーションの文を入れてたり、デバッガと通信用のためのクラスだったり、リリースビルドの時にいらないものを この定数（名前空間？）を指定してやると、コンパイルされません。（一応、デコンパイラで確認してみました） 大好きなあの子の名前をテストクラス名にしちゃった人とか、重宝するんじゃないでしょうかー。 これって、Flex-er の方にとっては常識なんですかね。 CS4erの自分は、初めてしって、ちょっとびっくり。 でも、true, false の切り替えが若干面倒ではあります。 Flash のメニューバーからの階層もかなり深いですし。 んー、一長一短。 ウ○コしたかったら、したらいいじゃない、って事ですかー。]]></description>
		<wfw:commentRss>http://djakarta-trap.net/blog/2009/12/conditional_compile01/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>セキュリティーサンドボックスを克服したい件。</title>
		<link>http://djakarta-trap.net/blog/2009/12/securitysandbox_01/</link>
		<comments>http://djakarta-trap.net/blog/2009/12/securitysandbox_01/#comments</comments>
		<pubDate>Tue, 01 Dec 2009 11:19:51 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[セキュリティサンドボックス]]></category>

		<guid isPermaLink="false">http://djakarta-trap.net/blog/?p=188</guid>
		<description><![CDATA[あ、ハックして画像をロードしたい、とかじゃなくて、そもそもの概念がよくわかっていなかったので、 自分なりに少し粘着質に調べてみた結果、少し理解が進んだ気がしたので、ここにシッカリ記録しておきます。 僕の貧弱な知識とテスト力ですので、間違いがあったら指摘ください。お願いしますー。 概要　（鬱陶しい例え話をするぜ） まずは、事の始まりであるエラー文を読みます。 Error #2044: ハンドルされていない SecurityErrorEvent : text=Error #2048: セキュリティサンドボックス侵害 : http://localhost/flash_RandD/RD_01/bin-debug/index.swf は http://myTestServer.net/uploadTest/img/Image085.jpg からデータを読み込めません。 見出しっぽいのが２つあります。 ハンドルされていない SecurityErrorEvent セキュリティサンドボックス侵害 1は、エラーイベントにリスナが立てられてないですよ、と言ってるんだと思います。 問題は２です。 なんなのよ、セキュリティサンドボックス侵害って&#8230; そこで、色々とテストをしてみた結果、僕の中の結論はこうです。 例えます。 セキュリティサンドボックス　=　国境 crossdomain.xml = 友好国がリストアップされた立て看板 で、最初のエラー内容を例えなおすと、 localhost 共和国の index.swf は、myTestServer.net 王国に入国しようとしましたが、友好国の立て看板に 自分の国がリストされてないにも関わらずなんかしようとしたので、国境の侵害と見なされました。 なので、エラーイベント（警鐘）を国境で鳴らしましたが、その警鐘は、ただ鳴っただけでした・・・ つまり、このエラーを出ないようにするためには、 友好国が書かれた立て看板に、localhost 共和国の名を入れて貰い、入国を認めてもらったらいいんです。 国はどこで、立て看板の在処はどこか、に気をつける さて、ここからが僕がハマってた問題。 結論から書きます。 ローカルPCは、国ではない。 なんか、「CDは株券ではない/菊地成孔」みたいですけど。 ローカルPCは国（サーバー）ではないんで、index.swf は立て看板があっても入っていいかどうか判らないので、 とりあえず侵入してしまいます。　強気なローカルswf さん。漢（オトコ）だねぇ。 これは、FileReferenceインスタンスを使って、ローカルPCからファイルをアップロード・ダウンロードする際にも適用されます。 なので、ローカルPCのswfファイルを実行してる限り、あるサーバー（国）からのファイル（資産）のダウンロードは、 URI（資産の在り処）さえ分かれば可能となりますし、ローカルPCのファイルのアップロードも、アップロード場所さえ 特定できて、書き込み可な状態であれば、書き込めます。 [...]]]></description>
		<wfw:commentRss>http://djakarta-trap.net/blog/2009/12/securitysandbox_01/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>AS3Unitで、手を抜いてテストをする方法。</title>
		<link>http://djakarta-trap.net/blog/2009/11/as3unit_fast_test/</link>
		<comments>http://djakarta-trap.net/blog/2009/11/as3unit_fast_test/#comments</comments>
		<pubDate>Tue, 24 Nov 2009 14:28:10 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Progression]]></category>
		<category><![CDATA[UnitTest]]></category>
		<category><![CDATA[AS3Unit]]></category>

		<guid isPermaLink="false">http://djakarta-trap.net/blog/?p=172</guid>
		<description><![CDATA[リリースしたコンテンツのコードがあまりにも酷いので、本で勉強しながらリファクタリングをしているのですが、 本で何度もリピートされるのが、ユニットテストやれ、やんねーヤツは死んでよしという言葉。 そこで、yossyさん a.k.a BeInteractiveの中の人の、AS3Unitを使ってみようか、と。 実際、AS3Unitのドキュメントに従いながらコードを書いていたのですが、ハタと行き詰まったので、メモ。 テストクラスって、クラス指定しかできない サンプルで上がってたのは、以下のようなコード。 CalculatorTestってクラスが、テスト用のクラスで、そのクラス自体をテストの仕組みに登録してるようです。 （AS3Unitライブラリがswcソースしか手に入れられないので、中が見れず、分析できてないです・・・） で、CalculatorTestクラスはこんな感じ。 Calculatorというのが、テストしたいクラスという事になります。 このソースを見ても分かるとおり、テストクラス（CalculatorTest）を別途作って、名前空間で指定したメソッドの中で テストしたいクラスのインスタンスを生成し、アサーションを入れる、ということになるようです。 リファクタリング本にもあったんですが、テストクラスの中で実際テスト対象にしたいインスタンスと同じ条件のインスタンスを作ってやる必要があるようです。 （ここら辺、認識を間違ってるかもしれないです・・・） これはメンドイ。 同じ条件のインスタンスを作る作り方が、そもそも手間すぎるし、 そんなの、条件が絡まりすぎてムリだよ、ママ・・・。 で、解決方法を捻り出してみたのが、コチラ。 MyTestのクラスメンバにTestTargetインスタンスを保存して、 名前空間＜test＞なメソッド内で、インスタンスにテストを委譲すれば良さそうですね。 便宜上ここではTestTargetってクラスになってますけど、実際は、テストしたいクラスに、 名前空間＜test＞を使ったテストメソッドを書き加えるだけなんで、殆ど問題ないんじゃないでしょうか。 今回は、わざわざmyTestもアクセス制御子をnamespace＜test＞にしてますけど、別にpublicでも動きます。 が、安全のため、名前空間を指定した方が良いでしょうし、テスト用関数だと見た目で解り易いので、 ＜test＞名前空間に指定してます。 < テストクラスのスタティックメンバにインスタンスを保存 > という作業自体は、Progressionで言えば、 シーンオブジェクトのテストしたいタイミングのイベントだったり、キャストの中だったり、どこでも書けそうです。 こんなの、常識かもしれませんねーww でも、自分の覚書のために、メモメモ。]]></description>
		<wfw:commentRss>http://djakarta-trap.net/blog/2009/11/as3unit_fast_test/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Progressionを精読してみる(1) -scene process編-</title>
		<link>http://djakarta-trap.net/blog/2009/11/read_progression_1/</link>
		<comments>http://djakarta-trap.net/blog/2009/11/read_progression_1/#comments</comments>
		<pubDate>Wed, 18 Nov 2009 19:13:46 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Progression]]></category>
		<category><![CDATA[SceneManager]]></category>

		<guid isPermaLink="false">http://djakarta-trap.net/blog/?p=142</guid>
		<description><![CDATA[実力を上げるには先達の思考を盗むに限るよねー、って事で、 Progressionのソースをコツコツと精読して行くシリーズ開始します。 最初は、シーン遷移がどうなってるのかを理解するのにトライします。 なお、Progression4ではコンフィギュレーションが４種類あって、それぞれの設定でシーン遷移の仕組みが変わります。 今回は、WebConfigを適用した場合を見ていくことにします。 クラス図 関係しているクラスのみで書くと、こうなるんでしょうか。 なお、UML図に関してはかなりテキトーです。 何か間違いがありましたら、是非ともツッコミ入れてください。お願いしますー。 処理の流れ 僕がソース追えた分だけですが、処理の流れを何となく書きます。 登場人物 Progression SceneManager SceneObject ExecutorObject CommandExecutor 起点となるのは、Progressionインスタンスであるmanagerのgotoを呼び出すところから始まります。 １．manager.goto このメソッド内で、sceneManagerに委譲をします。 シーン遷移に関しては、丸投げ状態みたいです。 Progression4で登場した、swf連結機能を使っている場合がif内ですかね。 ２．sceneManager.goto と、_gotoProgress まず、呼ばれたgotoメソッド内で、移動のためのイニシャライズ処理が行われてます。 「移動先が○○だった場合、××・・・」みたいな処理です。 あまり深く追わずにおきますが、基本的には、出発シーンのsceneId、目的シーンのsceneIdの 整合性確認と設定をしてるみたいです。 そこで、最終的には、private なメソッド、_gotoProgressが呼ばれます。 そして、_gotoProgressメソッド内で、実際の移動処理が行われます。 色々と、怒涛の前処理がありますが、最終的にやってる事は、現在のシーンのSceneObjectのインスタンスメンバであるExecutorObjectインスタンスを取得して、execute()する、という事です。 SceneObjectのインスタンスメンバ、_executor:ExecutorObjectには、 WebConfig適用時はCommandExecutorインスタンスが格納されています。 ３．_executor.execute　 CommandExecutorインスタンスのexecuteメソッド内の仕組みは若干トリッキーで、 結果的にCommandExecutor内の_executeFunctionメソッドが実行されます。 CommandExecutor(ExecutorObjectのサブクラス)から、super.executeメソッドが呼ばれている所があります。 その箇所で、_executorと関連付けられているSceneObjectインスタンスがイベントをディスパッチしているクダリがあります。 クラス図からも解ると思いますが、メソッド内にある_targetが、関連付けられているSceneObjectインスタンスです。 隠蔽するために、IEventDispatcher型の変数に格納されてます。 発行されているイベント（_event）は、２．のSceneManagerの_gotoProgressメソッド内で指定されたSceneEventです。 なので、ここが、atSceneLoad,atSceneInit等のメソッドの実行タイミングになるわけですね。 SceneManagerの_gotoProgressメソッドは、遷移の際に辿って行くSceneObjectインスタンスが存在する限り、繰り返し実行されます。 繰り返し実行されているカラクリは、_executorの実行が完了した段階で、ExecuteEvent.EXECUTE_COMPLETEの リスナ関数_executeCompleteが実行され、 _gotoCompleteが呼ばれ、その中で、 _currentSceneId、_destinedSceneId、_eventType の値から、以降に移動すべきシーンを判別しています。 判別の結果を踏まえて、再び_gotoProgress()が呼ばれる（もしくは次に移動すべきシーンがない場合は、遷移終了となる）、 という仕組みです。 まとめ 言葉で追っていくと中々解り辛いんですが、結局のところ、シーン遷移で一番頑張ってるクラスは SceneManagerクラス、という事になるんでしょうかね。 ソースを実際に読んでみて、自分が色々と勘違いしていたことがわかりました。 [...]]]></description>
		<wfw:commentRss>http://djakarta-trap.net/blog/2009/11/read_progression_1/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Progression で MVC的なサムシング (2)</title>
		<link>http://djakarta-trap.net/blog/2009/11/progression-mvc-2/</link>
		<comments>http://djakarta-trap.net/blog/2009/11/progression-mvc-2/#comments</comments>
		<pubDate>Tue, 03 Nov 2009 08:33:29 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[mvc]]></category>
		<category><![CDATA[Progression]]></category>

		<guid isPermaLink="false">http://djakarta-trap.net/blog/?p=115</guid>
		<description><![CDATA[ProgressionでMVC的にプログラム書こうと色々やってたら、全然関係ない切り分けパターンになってきたよ、の話。 その２。 MVCの「M」にとり憑かれる ProgressionでMVCっぽく、という事を考えると、行き詰るのは、 「・・・で、ダレをModel(アプリケーションのデータ)として扱うの？」という疑問でした。 Progressionの場合 公式ガイドに沿ってクラススタイルでコードを書いていくと、SceneObjectを中心にコンテンツを組んで行く事になると思います。 自分の場合もそれに倣って、SceneObjectを香盤表のようにしてコードを書くようにしてます。 そういうスタイルでやってると、どうにもこうにもMVC的な構造が作りづらいなー、と思ってました。 いや、構造が作りづらい、というより、だれがModelなのかが解からないから、切り分け方が解からない、みたいな感じかな。 具体的に困った場面は、あるシーン以下で、共用したい外部画像データがある場合でした。 具体例 （一般的な galleryコンテンツ） 例えば、こんな感じで、ギャラリーコンテンツを作ろうとしたとします。 ギャラリートップで、XMLを読み込みます。そのxmlに書いてあるサムネイル画像のURIを元に画像をロードして、表示します。さらに、サムネイルの数だけgallery detail sceneをnewして、ギャラリートップシーンにaddSceneしますよ、と。 detail sceneでは、大きな画像をロードして表示しつつ、サムネイル画像をランダムに２０個選んで表示しますよ、と。 ここで、MVCに憑かれてた僕としましては、画像URI情報の取り回し、どうするよ？という風に考えるわけですね。（ほとんどビョーキですねー） detail sceneをnewする段階で、引数で必要な画像パスを渡したらいいんですけど、それってMVC的ではないよなー、と。 それ以上に、「無作為に２０個選んで画像表示する」というクダリでは、同じシーンに複数回到着した時にも、毎回ランダム抽出しなきゃ要件満たせないわけなんで、引数で渡しちゃうとダメですよねー。 詰まるところ、SceneObjectとは無関係なところで、画像URI達を保持して、適宜引き出す（getする）必要があるのかなー、と。 で、色々な本を参考にして、MVCっぽくクラス構造を考えては試してみて、をやってみたものの、どーもシックリこない。 シックリ来ないっていうのは、どの方法も、Progressionの機能を活かした状態で、MVCっぽくできてない、って事です。 ここで、結構な暗礁に乗り上げた感がありました。 で、MVCを忘れて、オレオレ・パターン で、MとVとCのことは、一旦忘れることにしました。 可能な限りデータ層とそれ以外で切り分ける事に集中してみましょうよ、と。 gallery コンテンツでは、「画像URIのデータをどう共有して、どのタイミングで必要な情報を引き出すか」が問題であるわけですよね。 で、幾つかの試行錯誤をした結果、ワタシが一先ず考えたのはこんな感じ。 Progression的にはやっぱりSceneObjectに&#8221;Castをアド&#8221;とか書くのが一番解かりやすい気がするので、データを共有する場合も、SceneObjectを介して共有するのが良さそうかな、と。 さらに言えば、そのデータが要らなくなるタイミングも、Gallery Scene のatSceneUnloadで掴めるので、そこでデータを明示的に破棄すれば、アプリケーションとしてのメモリ節約にもなりそうですし。 今回は親シーンと子シーンの問題でしたけど、この方法なら、直接親子関係にないSceneObject間でも共通データを 共有することは簡単にできそうですね。 個人的に目からウロコだった、というか、アハ体験だったのは、protected static っていうアクセス制御。（図では、Abstract Gallery Scene　の imageURIs と getRandomPath） これで、スーパークラスが同じでさえあれば共通データに簡単にアクセスできるんですねー。 protected static、クラス設計の定石なのかもしれないですけど、自分はなかなか気づけませんでした・・・orz で、再度MVCを考える ここで、再度MVCを考えてみます。 色々と本を見てると、例として上がるのは「時計表示の仕組み」だったり、「ラジコンカーを操作する仕組み」だったり、アプリケーションというよりは、説明のために「ある機能の一部」を切り出したものばかりなので、ついつい、それくらいの小さな単位で考えなければならないような気がしてたんですが、実際は、もっと大きなところで考えなければならないのかもしれないなー、と。 今回の例で言えば、「ギャラリーコンテンツ」という単体アプリケーションであると考えれば、アプリケーションとして取り回さなければならないデータが何なのかは、自ずと絞られる気がします。 [...]]]></description>
		<wfw:commentRss>http://djakarta-trap.net/blog/2009/11/progression-mvc-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Progression で MVC的なサムシング (1)</title>
		<link>http://djakarta-trap.net/blog/2009/11/progression-mvc-1/</link>
		<comments>http://djakarta-trap.net/blog/2009/11/progression-mvc-1/#comments</comments>
		<pubDate>Sun, 01 Nov 2009 07:10:35 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[mvc]]></category>
		<category><![CDATA[Progression]]></category>

		<guid isPermaLink="false">http://djakarta-trap.net/blog/?p=100</guid>
		<description><![CDATA[プログラムのお作法として望ましいとされる、MVCパターン。 それをProgressionで実現するためにはどうしたらいいかを、自分なりにまとめてみます。 最初にオチを書いておきますが、 結局MVCとか無視した切り分けパターン　に落ち着きます。 progressionの機能を最大限に活かす事を最優先させたい僕は、結局MVC構造は邪魔になりました、という話です。 色々とプログラムをするにあたり、望ましいとされるMVC。 それを、Progressionで実践するためにはどうしたらいいのかを模索します。 だいたい、「flash で　MVC」って、どーすんのよ？ ペーペーの自分には解説できるほどの力量が無いという、そんなunko野郎なんで、 詳しくはエライ先生方や、著名人の本の解説を参照してください。 [ apeirophobia tozaki先生] http://blog.img8.com/archives/2007/11/003356.html http://www.img8.com/max2007/ [ 閃光的網站・弛緩複合体 -Review Division-　Aquioux 先生] http://aquioux.blog48.fc2.com/blog-entry-640.html [参考書籍] http://oreilly.com/catalog/9780596528461/ ActionScript 3.0 Design Patterns のMVC章（英語版pdf） 僕とProgressionと、MVC この１年くらい、MVC関連の本を色々読んだり、偉人flasherのブログのMVC記事を見たり、自分で実践してみたなかで、 ふと思ったんですよね。 Progressionでは、いわゆる「MVC」的な切り分けで考えない方がいいんじゃないか？ 全くのゼロスタートからMVCパターンでの実装をしたことがないのに、こういう事を書くのもどうかとは思うんですが・・・。 でも、Progressionで作ってると、杓子定規なMVCの切り分けがどうもやりづらい気がするんです。 （僕のMVCの解釈が間違ってるだけかもしれませんが・・・） 折角便利な機能を持ってるProgressionの良さを殺してしまう場面が何度もあったので、ここは思い切って、 MVCで切り分けるという前提をぶっ壊します。 不肖unko野郎のワタクシは、ここではものすごく乱暴に、 とりあえず、Progressionの機能を最大限に活かしつつ、イイ感じに切り分けといたらいいんでしょ？ くらいの感じでいきます。 記事タイトルを最初っから無視するという暴れん坊シリーズですが、また後日、詳細を記録していきます。]]></description>
		<wfw:commentRss>http://djakarta-trap.net/blog/2009/11/progression-mvc-1/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

