フォーラムへの返信
-
投稿
-
ご確認いただきありがとうございました。
ぜひ、複数画像に対応できるようにしていただけると助かります。書かれている通り、一つの添付ファイルに複数画像が登録されている場合の
対応も少なからず必要かとは思いますが、実はニーズとしては試した方法２に
書いたように、複数の添付ファイルフィールドをReports Connectの
イメージファイルフィールド名にカンマ区切りなどで指定できるようになると
うれしかったりします。
例えば外観写真と図面画像のように、明確に意味が分かれているものを
それぞれ別の添付ファイルフィールドに登録し、帳票側では外観写真はここに配置、
図面画像はここに配置、といったように両者を明確に区別して指定できるからです。ご検討の程、何卒よろしくお願いいたします。
inoさま
アドバイスいただきありがとうございました。実は3月の投稿の後、Locale.USを明示的に指定すると良さそうということがわかりましたので、
new SimpleDateFormat(“yyyy-MM-dd”, Locale.US).parse($F{日付})
のように実装を行い、その後特に問題には遭遇しておりません。
時間が経過してからのアドバイス投稿、ありがとうございました。
特に何もいじっていないのですが、今ReportsConnectでPDFを生成してみたら、
正しい西暦表示になっていました。。朝見た時は「平成2015年」が西暦変換された「4003年」という出力だったのですが。。
ありがとうございます。
Text Field Expressionには
new SimpleDateFormat(“yyyy-MM-dd”).parse($F{日付})
と指定しており、Patternには
yyyy年 MM月 dd日
と設定しています。また、
$F{日付}
にはkintoneの日付フィールドで取得される「2015-03-25」のような
形式の文字列が入ってきています。java.util.Date()では「2015-03-25」という形式の日付を正しく
認識できなかったので SimpleDateFormat を使用していました。逆に、new java.util.Date()を使って「2015-03-25」という形式のものを
扱う際、Text Field Expressionにはどのように記述されているのか
アドバイスをいただいてもよろしいでしょうか？
（純粋なJavaの話かもしれませんが。。）sweetie様
早々のご返答ありがとうございます。
そうですね、追加でInstallしているものの情報はよく出ているのですが、
そもそもビルトインされているフォントがなんなのかという情報が
KPSさんの資料などを見てもよくわからず、今回のような質問をさせていただきました。
ビルドインされているフォントはiTextというライブラリ次第なのですね。実はImpactというフォントを使いたいのですが、ライセンスの絡みもあるかも
しれないので、KPSさんの方で追加でInstallするのは難しいでしょうか？ドキュメントを見ると、確かにREST APIのファイルのダウンロードはAPIトークンの対象外になっていますね。。
https://developers.cybozu.com/ja/kintone-api/common-appapi.html#i-6サイボウズさんにはぜひ対応をしていただきたいところですが、こればかりは仕方がないので、今後対応されることを期待したいと思います。
ご確認ありがとうございました。
kintoneは込み入ったことをしようとすると逆に難しい、あるいはできないこともありますが、サービスをシンプルに保つというコンセプトもあるように思うので、今後APIレベルでも良いのでアプリ（テーブル）間連携を強化していただきたいものですね。
ReportsConnectの「標準のAPIの文法の範囲で、１回のクエリー文で読めるものをデータソースとするという方針」についても了解致しました。
また、印刷に特化したアプリを作るというのもなかなか斬新なアイデアですね。
諸々検討して、最適解を考えてみたいと思います。最初の話に戻ってしまいますが、なぜkintoneのテーブルではなく別アプリ（別テーブル）にしたいかというと、テーブルだと入力するところまでは非常に直感的でよろしいのですが、複数レコードにまたがるテーブルデータの集計や抽出ができないように思われるためです。（自前で作ればできる？）
かと言って、子レコード達の集計・抽出をやりたいが為に別アプリで子レコードを入力させようとすると、テーブルのような直感的な入力方法にはなりません。
あちらが立てばこちらが立たず状態ではありますが、要件を整理して、別アプリにしなければならないのか、あるいはテーブルで十分なのかを見極めた上で、帳票印刷のことも考えてみたいと思います。ありがとうございました。
早速のご検討とアドバイス、ありがとうございます。
アプリB側のルックアップからアプリA側の必要なフィールドをすべてコピーしておいて、アプリBで帳票出力するというのはできそうですね！これは一つの解だと思います。
しかしここで「コピー」という言葉が使われている通り、kintoneのルックアップはいわゆる完全なリレーションではなくて、ルックアップ時にコピーするだけのものなので、その後一方の値が変わっても、他方の値は置いてきぼりなんですよね。。（使い勝手を優先したkintoneの緩さ＝良い面でもあるのですが）
ですので話は飛躍しますが、親子テーブルのようなことをkintoneで実現しようとした場合、ルックアップはあまり使わず、ある意味自前でレコードID同士を結びつけるようなことをやっています。
また、操作感として、親レコードを作っり、そこから子レコードを複数作っていくという流れの方が自然なケースがあるので、先の話とも合わせて、最近はアプリアクションというのをうまく使うようにしています。
アプリアクションでアプリAからアプリBの新規レコード作成をキックする時に、アプリAのレコードIDを、アプリBの親レコードIDフィールドにコピーするのです。こうすることで、割ときっちりしたリレーション関係をAとBの間で作ることができます。
このような構造だと、アプリA側に関連レコード一覧パーツを置いて、アプリA.レコード番号＝アプリB.親レコード番号という条件で、アプリBの関連レコードを表示させることもできます。
（しかしルックアップを使わないので、Bのルックアップフィールドのリンクをクリックして親のAレコードを開くというようなことは自前で作らない限りできなくなりますが。。）ということで、上記のような構造であれば、アプリAからアプリBのレコードをREST APIでも引っ張れるのではないかと妄想しているのですがいかがでしょうか？
しかし、kintoneの標準的な作り方ではないので、ReportsConnect自体に無理な改変が入るのもあまり好ましくないとも思っていたり。。
