Feature #525
未完了XMLオブジェクトのリファクタリング
80%
説明
HTTPServiceで取得したオブジェクトをXML形式で持ちまわっていますが、
これをクラスに格納して持ちまわるようにリファクタリングしてもいいですか?
理由は、XMLにe4xでアクセスすると補完が効かないことと(データ構造をいちいち確認する必要がある)、bindingの対象として利用できないためです。
DB設計するにしても格納するデータ構造を整理できると楽なので。
yusuke kokubo さんが13年以上前に更新
- カテゴリ を ALL にセット
- 担当者 を Yasuhiro Morikawa にセット
- 対象バージョン を 0.0.5 にセット
お願いします~。
Akiko Takano さんが13年以上前に更新
e4x化したのは、XMLでフィルタリングしやすかったためです :)
たとえば、特定のプロジェクトのチケットを抽出するとか、文字列検索するとか、クライアント側での検索に実装しやすいのが理由でした。
(チケットのDueDateのフィルタなどがそうです。Objectだとこの機能は難しいので)
#内容はサーバの生XMLか、デバッグでチェックしていました(^^;
でも、どちらの実装でも利用したことがあるので大丈夫です。
Yasuhiro Morikawa さんが13年以上前に更新
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();
Akiko Takano さんが13年以上前に更新
Sticky側はこちらのほうでも良いかなと思います。
IssueListはリファクタリングの様子を見て、向いているタイプで扱っていただければと思います。
なお、今はStickyクラスは内部にViewのためのWindow(View)とデータ(モデル?)とアクションを持っていますが、上記の場合だとStickyクラスはデータのみを持つモデルになる感じでしょうか。
(説明まずくて申し訳ないです)
Yasuhiro Morikawa さんが13年以上前に更新
Akiko Takano は書きました:
なお、今はStickyクラスは内部にViewのためのWindow(View)とデータ(モデル?)とアクションを持っていますが、上記の場合だとStickyクラスはデータのみを持つモデルになる感じでしょうか。
(説明まずくて申し訳ないです)
その通りだと思います。
とりあえずViewとModelを剥離してSticky自体はPOJOなクラスとして、
アクションに関しては、View側に継承させるなり内部に定義するなりの方向で
如何でしょうか?
Sticky側はこちらのほうでも良いかなと思います。
IssueListはリファクタリングの様子を見て、向いているタイプで扱っていただければと思います。
HTTPServiceのresultに格納されるクラス == (POJO化された)Stickyである必要はないかと思っていますが、
ここはやりながら調整かなと思っています^^
Akiko Takano さんが13年以上前に更新
了解しました、ありがとうございます。
Javaも含めずいぶんフレームワークとか技術についていけてないので、勉強させていただきます(^^
Yasuhiro Morikawa さんが13年以上前に更新
Akiko Takano は書きました:
了解しました、ありがとうございます。
Javaも含めずいぶんフレームワークとか技術についていけてないので、勉強させていただきます(^^
いえー、私も大したことないんで色々教えてください(__)
Yasuhiro Morikawa さんが13年以上前に更新
- 期日 を 2010/09/08 にセット
- ステータス を 新規(New) から 担当(Assigned) に変更
着手します。1,2日ほどください。
Yasuhiro Morikawa さんが13年以上前に更新
- ステータス を 担当(Assigned) から 解決(Resolved) に変更
- 進捗率 を 0 から 100 に変更
更新履歴 r109 で適用されました。
Yasuhiro Morikawa さんが13年以上前に更新
- ステータス を 解決(Resolved) から フィードバック(Reopend) に変更
- 進捗率 を 100 から 80 に変更
間違ってcloseしてました。
大幅に書き直してしまったのでレビューお願いします。
yusuke kokubo さんが13年以上前に更新
量が多いのでざっくりとしか見れてませんが問題ないと思います。
#ところどころコメントが残ってるのが気になりますが…
個人的にはテストコードを作ってくれたのが嬉しいです^^
Akiko Takano さんが13年以上前に更新
コード拝見しました。元が泥臭いコードで恐れ入ります...m(_ _)m
久しぶりに、わたしもコミットしたいのですが、r109をベースにするとまだ付箋のプロパティが保存できないみたいですね。
trunk に入れるかbranch に入れるかどうしようか迷ったので、相談させて下さい。
Issue.as のクラスにPropertyを持たせると前の方法と同じで1つの*.dat に保存できますが、コードにコメントされているように、プロパティは別の *_prop.dat みたいに分ける方向でしょうか。
Issue.as の拡張クラスを作って Issue と Propertyを持たせるのはNGですよね...。
追加しようと思っているのは個人設定の部分で、こちらを受けて、付箋のデフォルトの色、フォント、透明度をカスタマイズできるようにする部分です。