Project

General

Profile

Feature #525

XMLオブジェクトのリファクタリング

Added by Yasuhiro Morikawa over 9 years ago. Updated about 9 years ago.

Status:
フィードバック(Reopend)
Priority:
通常(Normal)
Category:
ALL
Target version:
Start date:
09/03/2010
Due date:
09/08/2010
% Done:

80%

Estimated time:

Description

HTTPServiceで取得したオブジェクトをXML形式で持ちまわっていますが、
これをクラスに格納して持ちまわるようにリファクタリングしてもいいですか?

理由は、XMLにe4xでアクセスすると補完が効かないことと(データ構造をいちいち確認する必要がある)、bindingの対象として利用できないためです。

DB設計するにしても格納するデータ構造を整理できると楽なので。

History

#1

Updated by yusuke kokubo over 9 years ago

  • Category set to ALL
  • Assignee set to Yasuhiro Morikawa
  • Target version set to 0.0.5

お願いします~。

#2

Updated by Akiko Takano over 9 years ago

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

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

#3

Updated by yusuke kokubo over 9 years ago

  • Tracker changed from Defect to Feature
#4

Updated by Yasuhiro Morikawa over 9 years ago

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();

#5

Updated by Akiko Takano over 9 years ago

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

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

#6

Updated by Yasuhiro Morikawa over 9 years ago

Akiko Takano は書きました:

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

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

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

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

#7

Updated by Akiko Takano over 9 years ago

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

#8

Updated by Yasuhiro Morikawa over 9 years ago

Akiko Takano は書きました:

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

いえー、私も大したことないんで色々教えてください(__)

#9

Updated by Yasuhiro Morikawa over 9 years ago

  • Due date set to 09/08/2010
  • Status changed from 新規(New) to 担当(Assigned)

着手します。1,2日ほどください。

#10

Updated by Yasuhiro Morikawa about 9 years ago

  • Status changed from 担当(Assigned) to 解決(Resolved)
  • % Done changed from 0 to 100

更新履歴 r109 で適用されました。

#11

Updated by Yasuhiro Morikawa about 9 years ago

  • Status changed from 解決(Resolved) to フィードバック(Reopend)
  • % Done changed from 100 to 80

間違ってcloseしてました。

大幅に書き直してしまったのでレビューお願いします。

#12

Updated by yusuke kokubo about 9 years ago

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

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

#13

Updated by Akiko Takano about 9 years ago

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

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

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

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

#14

Updated by yusuke kokubo about 9 years ago

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

#15

Updated by Akiko Takano about 9 years ago

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

Also available in: Atom PDF