r-labs » RedmineAir

e4x化したのは、XMLでフィルタリングしやすかったためです :)
たとえば、特定のプロジェクトのチケットを抽出するとか、文字列検索するとか、クライアント側での検索に実装しやすいのが理由でした。
（チケットのDueDateのフィルタなどがそうです。Objectだとこの機能は難しいので）
＃内容はサーバの生XMLか、デバッグでチェックしていました(^^;

でも、どちらの実装でも利用したことがあるので大丈夫です。

Akiko Takano は書きました:

e4x化したのは、XMLでフィルタリングしやすかったためです :)
たとえば、特定のプロジェクトのチケットを抽出するとか、文字列検索するとか、クライアント側での検索に実装しやすいのが理由でした。
（チケットのDueDateのフィルタなどがそうです。Objectだとこの機能は難しいので）
＃内容はサーバの生XMLか、デバッグでチェックしていました(^^;

でも、どちらの実装でも利用したことがあるので大丈夫です。

なるほど、なるほど。
方針としては、HTTPService.xmlDecodeを実装して、
実際に利用するときはキャストして利用するイメージにリファクタリングしようと考えていました。
http://www.adobe.com/livedocs/flex/3_jp/langref/mx/rpc/http/HTTPService.html#xmlDecode

たとえば、Stickyクラスを定義しておいて

[Bindable]
class Sticky {
public var subject:String;
public var dueDate:Date;
}


HttpServiceの結果取得時に、以下の感じで利用しますがいかがでしょう？

httpService.addEventListener(ResultEvent.RESULT, function(e:ResultEvent):void {
// xmlDecoderを利用して任意のクラスに変換
var sticky:Sticky = e.result as Sticky;
});
httpService.send();

Sticky側はこちらのほうでも良いかなと思います。
IssueListはリファクタリングの様子を見て、向いているタイプで扱っていただければと思います。

なお、今はStickyクラスは内部にViewのためのWindow（View）とデータ（モデル？）とアクションを持っていますが、上記の場合だとStickyクラスはデータのみを持つモデルになる感じでしょうか。
（説明まずくて申し訳ないです）

Akiko Takano は書きました:

なお、今はStickyクラスは内部にViewのためのWindow（View）とデータ（モデル？）とアクションを持っていますが、上記の場合だとStickyクラスはデータのみを持つモデルになる感じでしょうか。
（説明まずくて申し訳ないです）

その通りだと思います。
とりあえずViewとModelを剥離してSticky自体はPOJOなクラスとして、
アクションに関しては、View側に継承させるなり内部に定義するなりの方向で
如何でしょうか？

Sticky側はこちらのほうでも良いかなと思います。
IssueListはリファクタリングの様子を見て、向いているタイプで扱っていただければと思います。

HTTPServiceのresultに格納されるクラス == (POJO化された)Stickyである必要はないかと思っていますが、
ここはやりながら調整かなと思っています＾＾

了解しました、ありがとうございます。
Javaも含めずいぶんフレームワークとか技術についていけてないので、勉強させていただきます(^^

Akiko Takano は書きました:

了解しました、ありがとうございます。
Javaも含めずいぶんフレームワークとか技術についていけてないので、勉強させていただきます(^^

いえー、私も大したことないんで色々教えてください（＿＿）

量が多いのでざっくりとしか見れてませんが問題ないと思います。
＃ところどころコメントが残ってるのが気になりますが…

個人的にはテストコードを作ってくれたのが嬉しいです＾＾

コード拝見しました。元が泥臭いコードで恐れ入ります...m(_ _)m

久しぶりに、わたしもコミットしたいのですが、r109をベースにするとまだ付箋のプロパティが保存できないみたいですね。
trunk に入れるかbranch に入れるかどうしようか迷ったので、相談させて下さい。

Issue.as のクラスにPropertyを持たせると前の方法と同じで1つの*.dat　に保存できますが、コードにコメントされているように、プロパティは別の *_prop.dat みたいに分ける方向でしょうか。
Issue.as の拡張クラスを作って Issue と　Propertyを持たせるのはNGですよね...。

追加しようと思っているのは個人設定の部分で、こちらを受けて、付箋のデフォルトの色、フォント、透明度をカスタマイズできるようにする部分です。

trunkに入れるのは多少安定してからが望ましいですが
branchなら自由にいじってもらって構いませんので。

お返事ありがとうございます。
では、ブランチ側のコードをベースにテストしてみます。