プロジェクト

全般

プロフィール

Feature #525

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

Yasuhiro Morikawaほぼ8年前に追加. 7年以上前に更新.

ステータス:
フィードバック(Reopend)
優先度:
通常(Normal)
カテゴリ:
ALL
対象バージョン:
開始日:
2010/09/03
期日:
2010/09/08
進捗率:

80%

予定工数:

説明

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

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

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

履歴

#1 yusuke kokuboほぼ8年前に更新

  • カテゴリALL にセット
  • 担当者Yasuhiro Morikawa にセット
  • 対象バージョン0.0.5 にセット

お願いします~。

#2 Akiko Takanoほぼ8年前に更新

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

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

#3 yusuke kokuboほぼ8年前に更新

  • トラッカーDefect から Feature に変更

#4 Yasuhiro Morikawaほぼ8年前に更新

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 Akiko Takanoほぼ8年前に更新

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

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

#6 Yasuhiro Morikawaほぼ8年前に更新

Akiko Takano は書きました:

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

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

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

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

#7 Akiko Takanoほぼ8年前に更新

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

#8 Yasuhiro Morikawaほぼ8年前に更新

Akiko Takano は書きました:

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

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

#9 Yasuhiro Morikawaほぼ8年前に更新

  • 期日2010/09/08 にセット
  • ステータス新規(New) から 担当(Assigned) に変更

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

#10 Yasuhiro Morikawaほぼ8年前に更新

  • ステータス担当(Assigned) から 解決(Resolved) に変更
  • 進捗率0 から 100 に変更

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

#11 Yasuhiro Morikawaほぼ8年前に更新

  • ステータス解決(Resolved) から フィードバック(Reopend) に変更
  • 進捗率100 から 80 に変更

間違ってcloseしてました。

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

#12 yusuke kokuboほぼ8年前に更新

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

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

#13 Akiko Takano7年以上前に更新

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

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

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

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

#14 yusuke kokubo7年以上前に更新

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

#15 Akiko Takano7年以上前に更新

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

他の形式にエクスポート: Atom PDF