r-labs » RedmineAir

提案ありがとうございます。

ぼくの会社では必要なさそうですが、これはあった方が良さそうですね。
というか、設定ファイルをわざわざURLとkeyで分けてるのはXMLで保存して取得する方法がわからなくて断念したという経緯があるので「設定のXML化」は是非ともしたいところです…＾＾；

前向きに検討したいのですが、これをやろうと思うと画面のレイアウトも変わってくるのですぐにはできないかもです。

＃誰かが実装してくれれば大歓迎ですが＾＾；

(案をメモ)

複数Redmineを運用するときには個々のサイトを識別するのはURLになる。
なのでURLがキーになってその他APIKeyなどが紐づくような感じになる。

今はURLとKeyを個別のTextFieldになるけど将来的には
URLを選択ボックスにして複数のRedmineを切り替えられるようになったらよいかも。

サーバサイドのアプリ(Flex)では、設定ファイルをXMLで読み込むことは行っていました。
ローカルで持つ(Airアプリ)は、わたしも今回が初めての経験なので、実装が良くわかっていないのですが、下記が参考になりそうです。

• XML 環境設定ファイルの読み取りおよび書き込み
  • http://www.adobe.com/jp/devnet/air/ajax/quickstart/xml_prefs.html

ウォッチと担当のどっちをデフォルトにするかとか、0件の場合のアラートを表示させるかどうか...などの設定を個人でもほしいなと思ったので、まずは設定のXML化を切り出してみようと思います。

【複数のRedmineを管理するUI案】

SQLServerのManagement Studioみたいに画面を2ペインに分けて左側に複数のRedmineサイトを並べて右側にチケット一覧を表示するようにしたらどうだろう？
サイトごとの設定が必要になったときも設定画面への誘導が簡単にできそうな気がする。

yusuke kokubo は書きました:

【複数のRedmineを管理するUI案】

SQLServerのManagement Studioみたいに画面を2ペインに分けて左側に複数のRedmineサイトを並べて右側にチケット一覧を表示するようにしたらどうだろう？
サイトごとの設定が必要になったときも設定画面への誘導が簡単にできそうな気がする。

試しにcacooで画面のイメージを作ってみました。

SQL Serverユーザなので、イメージは判ります。ありがとうございます

この案でもいいと思いますが、デフォルトは左でプロジェクトをクリックするとGridのデータも変更されるけれど、複数プロジェクト（複数Redmine）を同時に見たい場合もありますよね。
この場合、新規にウィンドウを立ち上げるというのが良いかなと思っています。
そこまではまだ先っぽいですが、可能です。

この場合、新規にウィンドウを立ち上げるというのが良いかなと思っています。

表示したいプロジェクトにチェックをつけるとチケット一覧に表示されるようにしたら良いのかなーとも思います。
(それをするとちょっと実装が面倒そうですが)

そこまではまだ先っぽいですが、可能です。

お任せっぱなしですみませんがお願いしますm(_ _)m

落ち着いたので着手しようと思います。
どなたか他に実装担当したいと希望される方、いらっしゃいますか？

本来は、自分がアクセスできるRedmineとプロジェクト一覧が見えて、そこをクリックしたタイミングでデータをロードするほうがいいのですよね。
ただ、ちょっと時間がかかるのと、Look&Feelを確認してもらうため、まずはこの案でいこうと思っています。

• いままでと同じで、URLとKeyのみ指定でHTTPServiceからデータ取得(e4x)
• issueList = new XMLListCollection(event.target.lastResult.issue)　でlistが取れる
• ここから、プロジェクトを抽出するのは、こんな感じ
  • issueList.project as XMLList
    • ここから、重複するプロジェクトを取り除けばよい

ただ、この構成だと、プロジェクトの親子関係はわからないので、kokuboさんの希望の画面からははずれちゃいますね。
また、チケットが無ければ、プロジェクトもツリーに出てきません。

事前に、アクセスできるプロジェクトを取得しないといけませんね。
これはもう一歩先でやりましょうか？　それとも、最初はプロジェクト一覧を取得するようにしてしまい、そのあとでチケットを取りにいくようにしましょうか？

事前に、アクセスできるプロジェクトを取得しないといけませんね。
これはもう一歩先でやりましょうか？　それとも、最初はプロジェクト一覧を取得するようにしてしまい、そのあとでチケットを取りにいくようにしましょうか？

最終的な完成形はなんとなく認識を共有できてる感じがする
(SQLServer Management Studioみたいな感じでサーバに接続してプロジェクトからツリーでつながる)
のでakikoさんにとってやりやすい方法で進めてください。

ちょっとここに書くのが遅すぎたかもしれませんが、考えたことをメモしておきます。
複数Redmineの処理について自分がイメージしてることです。

※※あくまでもメモなので違った実装に手をつけてても気にしないでください

1. 画面に何も表示されていない状態から「接続」をクリックしてRedmineサイトを追加する
2. ツリーを展開すると/projects.xmlを読み込んでプロジェクト一覧を取得する
   1. プロジェクトは親子関係を考慮して並ぶ
3. 展開されたプロジェクトをクリックすると/issues.xml?project_id=xxxを読み込んでチケットを一覧に表示する
4. 1度取得したチケットはキャッシュしておいてユーザーが再読み込みしたタイミングでサーバに取得しにいく

途中経過ですが、挙動が変わってくるので、これでいいかどうか書き込みます。

1. 現在は登録されているURLとKeyをもとに、起動直後に自動でデータを取得しています。(issues.xmlから)
2. プロジェクトツリーの構成にした場合は、下記のような挙動となるが、これでOKでしょうか？

• 登録されているURLとKeyをもとに,起動直後に project.xml を参照しに行く。
  • チケットの取得は行わない。
• プロジェクトツリー描画後、ユーザが希望のプロジェクトをクリックしたアクションで、はじめてチケットデータを取りに行く。
  • データ取得はプロジェクト単位。
  • issues.xml にプロジェクトのクエリをくっつけてサーバ側で絞り込んだ結果をもらう。

まず、『ユーザのクリックのアクションで、はじめてチケットデータを取りに行く』という動きになるのはOKかどうか確認したいのですが、如何でしょう。（今までの動作と動きが異なります）

また、プロジェクト一覧の中からプロジェクトを選択しても、チケットのないものもありますので、そういったプロジェクトもツリーに表示してOKでしょうか。

最初に自動で全チケットを取りにいくのであれば、チケットのあるプロジェクトのみを絞り込むこともできますが、この場合は、
全チケットを先に取得して、クライアント側（Airの側）で、チケットのなかからフィルタをかけてプロジェクト単位で取り出すことになります。

Redmineの返すXMLは、どちらにしてもmxmlのTree構造に利用するデータとしては向いていないので、Air側でいったんXMLを変換する作業が発生します。

＃ほんとうは、Redmine側の返すXMLを、Flexが扱いやすいかたちに拡張するのが楽なのですが、そういう希望は通らないでっしょうね。SQL ServerのようにSQLでXMLを好きな形に変換できるわけではないので、やや面倒です(^^;

まず、『ユーザのクリックのアクションで、はじめてチケットデータを取りに行く』という動きになるのはOKかどうか確認したいのですが、如何でしょう。（今までの動作と動きが異なります）

OKです。ぼくの考えてたことと同じです。

また、プロジェクト一覧の中からプロジェクトを選択しても、チケットのないものもありますので、そういったプロジェクトもツリーに表示してOKでしょうか。

これもOKです。
最初からそこまで考慮に入れなくてよいと思います。

＃ほんとうは、Redmine側の返すXMLを、Flexが扱いやすいかたちに拡張するのが楽なのですが、そういう希望は通らないでっしょうね。SQL ServerのようにSQLでXMLを好きな形に変換できるわけではないので、やや面倒です(^^;

そうなんですか…。ちょっと面倒ですがRedmineAir側で頑張るしかなさそうですね。

了解しました。

メイン画面の分割（設定と一覧を分離) -> プロジェクトツリーでの表示 -> 複数Redmineを登録可能な設定をもてるようにする、といった作業が必要になるなと感じたので、助かります。

放置してしまっていた複数化ですが、ご意見伺えれば幸いです。

わかりにくければ、図を描いてみますので...。

• 複数Redmineがある場合、取得結果を1つのリストにまとめて見せるのはNGでしょうか？
  • Redmineごとにリストの画面を作ったり切り替えたりするのは難しい気がしています。
  • Windowオブジェクトを動的に複数生成しないといけなさそうで、扱いにくいなと思っています。
  • 起動時、もしくは更新アクションのタイミングで、複数のデータソースから一度に取得し、表示の際にはまとめて表示します。
  • もちろん、指定のRedmineや指定のプロジェクトを選択した場合は、フィルタリングして対象のものだけをリストに表示する感じです。

• 関連するRedmineの情報が変わったり、参照対象から外れた場合、先に永続化して保存してある付箋データは、削除したほうがいいのでしょうか。それとも、単独で付箋は付箋としてActivateできるほうがいいでしょうか。
• 同様に、RedmineのURLを変更したい場合は、削除 -> 再登録という操作のほうがシンプルでしょうか。

自分もなかなか関われなくてすみません…＾＾；

1. チケットリストの見せ方

問題ないと思います。
現状を考えると1番シンプルな方法だと思うので。

2. 対象RedmineのURL更新や削除の場合

• 関連するRedmineの情報が変わったり、参照対象から外れた場合、先に永続化して保存してある付箋データは、削除したほうがいいのでしょうか。それとも、単独で付箋は付箋としてActivateできるほうがいいでしょうか。

削除で良いと思います。
＃最初のうちはそんなに気にせず作って後から考えても良いかもしれません

• 同様に、RedmineのURLを変更したい場合は、削除 -> 再登録という操作のほうがシンプルでしょうか。

そうですね。
URLを変更ってそんなに滅多にすることではないと思うので
作り手側の作りやすさを優先して良いと思います。

お返事ありがとうございます。
＃skillmapsもありますしね(^^

いろんなAirのUIやサンプルコードを見たりして悩んでいたのですが、まずはシンプルにしてみます。
ブランチとマージしたタイミングでどうかなと思ったのですが、結構実装が変わりそうなので、別途ためしてアップしてみます。

かっこいい！

試してみました。
すごいですね！見た目がかなりカッコよくなっています。

第一ステップとしてはとても良いと思います。
必要があればブランチにコミットしてください。

r113 に、ひとまずAntでもビルドできる状態までコミットしました。
Burritoで作成しましたが、Flex4.1をベースにしているので、一応r-labsのHudsonや開発者の皆さんの環境でビルドできると思います。

• ant compile -> swfの形にビルド
• ant run -> adl でプログラム起動

下記のような変更や制限があります。

• Viewとロジックの分離のために、AbstractViewHelper の利用をしてみています。
  • Ref: http://www.adobe.com/jp/devnet/flex/articles/imxmlobject_interface_04.html
  • ちなみに、もとのソースはMITライセンスです。せっかくなので、パッケージ構成もふくめそのまま利用させておらおうかと思います。
  • FxUGのnobuさんにお話をしてみます。（nobuさんのCopyrightをそのまま保持する形）

• ロギングのテストを行っています。
  • as3corelib.swc というバイナリになったライブラリを利用しています。
  • 上記は暗号化にも利用できます。
  • http://github.com/mikechambers/as3corelib
  • 必要があれば、こちらもソースからビルドする形で利用するのもいいかと思います。

• 付箋は実装されていません。
• NativeMenuは実装していません。
• とりあえず国際化はなしで英語のみです。
• 現在のRedmineAirとインストールパスがかぶらないようにしてください。
• Haloスキンを当ててみています。

Redmineの操作には、XMLを結構利用しています。
いまはひとつのASの中でHTTPリクエストからデータ取得を行っていますが、Redmine用のクラス（コントローラ）を作成し、Observerパターンみたいな感じで複数のRedmineコントローラの動作を管理するような方向が良いかと思います。

もう一回、手元でパッケージ化したものをアップします。

ありがとうございます。試してみました。
プロジェクトでフィルタリングできる仕組みがすごく便利だと思いました。
機能的には現状バージョンにだいぶ近づいてきた感じですね！

大きな不満はありませんが、ちょっと気になった点について

• 全体のwindowのサイズは固定にしますか？
• Redmineのadd, edit, removeはRedmine Listのすぐ下で良いと思います
  • 真下にあると見つけるのに時間がかかるので
• 画面下部にチケットへのリンクを表示してますが現バージョンみたいに一覧のチケットNoをクリックで遷移するようになっていても良いかと思います
  • ちょっと表示領域を取り過ぎているような感じがします
• チケットのxmlを表示する領域はxmlを見やすくレンダリングした画面と切り替えられるとすごく便利そうですね(先の話)

また、できればコミット漏れの防止の兼ねて、Hudsonでのビルドを行っていきたいのですが、どうするのが良いでしょう？

だいぶ新バージョンができつつあるので、
現trunkはtag付けして凍結させて、新バージョンをtrunkにしても良いかと思います。
もしくはGitHubにリポジトリを移行するかですが。
(Mercurialはゴメンなさい…)

ご確認ありがとうございます。
また、haruさんにもビルドを試していただいたみたいで、こちらもありがとうございます。

UIの面はとても重要なので、できるだけちょっとした改善も加えていただくほうが良いと思います。
皆さんの環境で試せるようにしますので、もう少しお待ちください。

チケットのxmlを表示する領域はxmlを見やすくレンダリングした画面と切り替えられるとすごく便利そうですね(先の話)

そのあたりの楽しい動作は好きなので、実装すると思います。

また、リポジトリはこの際どこでも構いません。GitHubでも構いませんので、場所だけ作っていただければ幸いです。

＃すごく汚いコードなので（汗）リファクタリング必須ですが、アジャイル風にがんばります...。