みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
ほんとはチポさんの仰る通り全部スクリプトで動かせば済みますが、
標準の検索機能をそのまま使いたいのであれば、
OnModeEnterで検索モードに切り替えた時点でグローバル変数等にフラグを立て、
検索実行時にはフラグクリア、未実行でブラウズに戻ってきたらレイアウト分岐等の後処理を行わずにフラグクリア、
といった方法で制御はできます。OnModeExitでも考え方は同じ。
ただ、通常の動作をフックするスクリプトトリガにグローバル変数絡めると、
後々まで設計上の見通しは悪くなります。
可能であれば、処理が全て見渡せるスクリプトで対応した方が良いでしょう。
全く同じメイン画像の、レイアウト上での表示サイズ変更しかしていないのであれば、
ボトルネックは幾つかに絞り込めるはずです。
サーバーの情報はありませんが部署ということなので、サーバーまたは代わりにProを使っているとして。
1．ホスト機の処理性能不足
2．ネットワークの帯域不足
3．クライアント機の処理性能不足
この辺がボトルネックの可能性が高いです。
1や2は、メイン画像のレンダリング、つまりレイアウトとして表示すべきデータの生成が、ホスト側で事前に行われている、という前提です。
3は、レンダリングがホストでもクライアントでも影響しえます。
ただ、レコード切り替えが瞬時から2~3秒というのはかなり異常で、全てのボトルネックが積み重なっての結果かも知れません。
すぐに試せる切り分け及び改善の案としては、次のようなものが考えられます。
・メイン画像として表示するのを、必要サイズで生成したサムネイルに切り替えてみる
・表示サイズを色々変えて、急速に遅くなるポイントがないか確かめる
・スタンドアロンで表示させてみる
残念ながらFileMakerの変数は、一般的な言語のそれとまったく異なります。
多次元配列はできませんし、DictやMap様の任意のキーも扱えません。
ver.16であればJSON関連の関数である程度代用できますが、
ver.12となると、AdvacedならDictを扱えるカスタム関数が役立つかも知れません。
Proしかないのであれば、素直に一次元配列2つ以上の組み合わせと考えた方が早いです。
値一覧は、統合的なインポートエクスポートの機構を持っていない要素です。
ValuListItems()による取得は、デザイン関数という副作用の無い関数による取得であって、エクスポートではありません。
結果、カスタム値を使った値一覧は、GUIによる手作業を使わなければ、ファイル間で移動できません。
無難なのは、現在カスタム値として入力してあるテキストをグローバル格納のフィールドに入力し、
それを値一覧が参照するフィールドとして指定する、という方法です。
中身が改行区切りのテキストであれば、カスタム値の場合と同じように認識してくれますし、
グローバル格納フィールドであればTOGを無視してアクセスでき、インポートエクスポートも可能です。
ただしグローバル格納を用いるため、共有環境ではクライアントからの永続的な書き換えができなくなります。
そこで、値一覧用の元データを入れておく非グローバル格納フィールドを用意しておき、
OnFirstWindowOpenトリガや、その元データフィールドのSaveトリガなどを使い、
値一覧が参照するグローバル格納フィールドに、元データから内容をコピーする、といった仕組みを用意する必要があります。
Windowsでしか確認してませんが、FileMaker 16はドロップでOnObjectModify発火します。
トリガで呼び出すスクリプトで、レコードの確定と、
できればGetLayoutObjectAttribute()で変更前後のMD5を取っておき比較して、
違っていればサムネイル更新、という流れで行けそうです。
マニュアル内の関数リファレンスに載ってます。
自分達がわかりやすければというよりは、規模と環境に応じて一貫した規則になっていれば、
これが正解というものは無いという状況です。
たとえばTOがせいぜい5つ、TOGもひとつで済むような小規模なソリューションで、
重厚な命名規則を採用するのは馬鹿げています。
私はこういうケースで、迷わずシンプルにテーブル名をそのまま使います。
中規模になればある程度TOGを切っていくでしょうから、最低限TOGを示す箇所が必要だと思います。
無難なのは先頭に付けた「TOG名_テーブル名_用途」などといった形式です。
用途部分は複雑になりかねないので、さらに区切り文字を決めておいた方がよいでしょう。
大規模や複数人での開発、あるいは長期的に手を入れていくソリューションなら、
全てのレイアウトに異なるTOGを用意したり、そもそもTOGの作り方自体に規則があるはずです。
またODBC等外部との連携次第ではASCIIのみで名付ける必要があり、
文字種の制限が増えるため更に区切りに工夫が必要です。
ちなみに、規模や用途によらず常に「_テーブル名」のTOは全テーブル分用意しています。
これはそのテーブルのメンテナンス用として、表形式のレイアウトに割り当てています。
-
Mozさんの言うように宗教戦争になってしまうのは、TOGをどういう定義で捉えるかに決まりがなく、
それ次第でリレーションシップグラフ全体の見え方が大きく変わるためです。
命名の前にリレーションシップグラフのモデリング方針、つまりTOとTOGの規則を決めた方が良く、
命名はその規則を無理なく表現できるものにすべきです。
方針にはたとえば有名所で Anchor/Buoy というスタイルがあります。
Anchor/Buoyの後に
http://notonlyfilemaker.com/2016/09/lif … chor_buoy/
他にもモデリングの手法は色々あって、全体的な方針を決めるものから、
局所的な目的のためのものまで様々です（リンク先はNotOnlyFileMakerさんの記事ばっかりです）。
なお、こういった手法全てに精通する必要は全く無いし、そもそもそれは、
すでに自分で使っている組み方を誰かが整理して一般化し、名付けただけかも知れません。
マジックキー
http://notonlyfilemaker.com/2016/03/mag … reporting/
バーチャルリストで目次を生成する
http://notonlyfilemaker.com/2017/02/vir … -contents/
Fast Summary
http://notonlyfilemaker.com/2017/03/fast-summaries/
日々手入れしているソリューションの場合、要望を受けて何らかのUIを実現するために、
データモデリングとはやや意味合いの異なるリレーションシップを追加する、
といったケースもあって、TO名やTOGの構成が雑然としやすいです。
そういったものにも対応していこうとすれば、無理に細かなパターンのルールを設けるより、
緩やかで基本的な、壊れにくい原則だけ持っておくのが無難です。
-
参考に、大昔FileMakerの命名規則について議論したスレッド。
https://groups.google.com/forum/#!topic … xHozylLLlc
無難なのは、2週間単位や月単位といった集計基準となるテーブルとそのレコードを用意し、
記録と日付の範囲でリレーションシップを定義。
時間数を集計テーブル側でSum()すれば合計時間が出ます。
集計フィールドの結果は特殊なため、GetSummary()を使わないと計算式で扱えません。
> textに変換して取り込むかなど工夫してみます。
まっとうなCSVなら中身は単なるテキストなので、拡張子変えるだけでFileMakerはテキストとして認識します。
ただ、CSVのフォーマットが不安定であれば、改行やエスケープの扱いなど、
FileMakerに取り込んだ後自力で分割する処理の方が大変になる気がします。
出力側に不安定なフォーマットをやめてもらえるならそれが一番ですが、
多少面倒でも、インポート用のテーブル用意して、分割はFileMakerに任せた方が楽かも知れません。
試してないけど、データがタブ文字を含まないなら、TSVとして取り込んだらいける？
「うまくいきません」がどううまくいかないのかヒントが無いと分かりません。
思った通りの画像が生成されないのか、エラーメッセージが出るのか、スクリプトが途中で停止するのか、等々。
たとえばスクリプトであれば、Get(最終エラー)等を使ってどううまく行かないのか、確認する必要があります。
Advancedのデバッガが使えると楽ですが、通常のProでも、細かく最終エラーを取得してグローバル変数などに追記するなどすれば、
どの箇所で想定外の動きをしているのかは追えます。
それでも案内するなら、トリガのタイミング等で失敗しているか、
リレーションシップで失敗しているか、どちらかの可能性が高いと思います。
トリガなど使わず画像の更新処理をボタンで実行し、画像大の更新まで含めてスクリプトで行い、
そのままサムネイルの生成を行うようにした方が、問題発生のポイントは減ると思います。
「小さな画像ファイル」が、FileMakerのサムネイル生成機能を使って問題ない内容であれば、
画像の更新作業を一連のスクリプトとし、その中でサムネイルの更新も自動で行えば目的に適うはずです。
Hiroさんの勘違いだと思います。
ひとつのフィールドにふたつのレイアウトオブジェクトを置いているのは、
一方はそのまま入力、一方はトリガを使って…という仕組みを作りかけだからでしょうか。
フィールドは「原稿」ひとつ。
そのフィールドを参照するテキストフィールドレイアウトオブジェクトとして、
最初に入力を行う「投稿」レイアウトオブジェクトと、
その後その校正作業を行う「校正」レイアウトオブジェクトがある。
「校正」レイアウトオブジェクトから行った変更が、自動的に書式設定された状態にしたい、
ということでは？
FileMakerだけでやるには、テキスト編集時のイベントが少なすぎて辛いです。
チポさんの案のようにボタンを絡めないと編集しにくいでしょうし。
diffやfcの様な外部のテキスト差分比較用のコマンドを使うのはどうでしょうか。
ただコマンドの出力をFileMakerで加工したり、OSに依存するのも嫌なので、
私なら https://github.com/sergi/go-diff とかで差分を取って、
FileMaker用に加工して返すプログラムをGoで書いてしまいます。
SQLベースで考えると、JOINの種別やWHERE句での絞込などが抽象化されてしまい、
またSQLでいう表の結合とは異なる概念のため、むしろ理解しにくいかも知れません。
= 照合フィールドの値が等しい。これはinner joinでしょうか？
はい、SQLでのINNER JOIN同様、参照側に一致したレコードのみが関連します。
あくまで結合ではなく関連です。
≠ 照合フィールドの値が等しくない。これは何でしょう？
< 左側の照合フィールドの値が右側の照合フィールドの値よりも小さい。これは何でしょう？
≤ 左側の照合フィールドの値が右側の照合フィールドの値よりも小さいか等しい。これは何でしょう？
> 左側の照合フィールドの値が右側の照合フィールドの値よりも大きい。これは何でしょう？
≥ 左側の照合フィールドの値が右側の照合フィールドの値よりも大きいか等しい。これは何でしょう？
これらはSQLで非等価結合と言われるものが最も近く、その名の通り不等号等で関連が決定します。
SQLでは非等価結合は遅いためそう使われるものではありませんが、
FileMakerでは等価結合同様の速度で参照できるため多用します。
x 照合フィールドの値に関係なく、左側のテーブルのすべてのレコードを右側のテーブルのすべてのレコードに一致させる。これはleft outer join、またはright outer joinでしょうか？
SQLで最も近いのはOUTER JOINですが、結合ではありません。
参照側の全てのレコードから非参照側の全てのレコードが関連する、という状態です。
自己連結リレーションというものがあります。これはSQLでいうところの自己結合になるんでしょうか？
これも、結合を、関連というFileMaker固有の概念で置き換えれば、自己結合が最も近いです。
-
FileMakerのリレーションシップはSQLのような問い合わせではなく、
TOGと呼ばれるFileMakerでのモデリングの基盤であり、アプリケーション側にコンテキストを提供します。
リソースとして定義され、双方向で、結合というより参照可能性を決定します。
またSQLで非効率とされる非等価結合なども多用して、レコード同士の関連性をデザインします。
FileMakerのモデリングは、SQLが持つ創発的な柔軟性は持ち合わせませんが、
照合のグラフによる定義としてのデータ構造は、理解してしまえば非常に手早く扱えます。
> 例えばスベースが4個以上あるとき3個目で改行
これをそのまま式にしてしまえば大丈夫ですよ。
Case(PatternCount(社名; " ") > 3; //スペースが4個以上
Replace( 社名; Position( 社名; " "; 1 ; 4 ); 1; "¶" ); //3個目のスペースを改行に置換
社名 // スペースが3個以下の場合
)あとは、社名フィールドの長さや、改行後の二行のバランスなど、
判定条件を増やしていくことが考えられます。
HTTPで一般的に言うセッションは単純な仕組みで、
サーバーとクライアント間で何らかのキーを共有し、
それを元にサーバー側に用意したデータストアを特定する、という程度のものです。
cookie云々は、そのキーの送受信と永続化にcookieを使っている、というだけです。
元々HTTPの通信はステートレスでセッションなんて仕組みはありませんし、
cURLがcookieを保存しないからセッション維持できない、というのは少しずれています。
cookieを使ってキーを毎度送受信しなければセッションが切れるのはブラウザでも同様で、
ブラウザは単にcookieを自動送受信してくれてるだけです。
もう一つの質問の方に書きましたが、セッションを維持したければ、
セッション開始時に取得したキーを -b か -h で指定してリクエストします。
今時少ないとは思いますが、サーバー側の実装でセッションキーが毎回変わるなら、
そのたびに毎回レスポンスからcookieを取り、リクエストにそれを指定します。
注意すべきは、サーバー側がザルな実装で、
GETでクエリストリングとしてセッションキーを送れてしまう場合でも、
必ずcookieで渡すようにしなければ、セッションハイジャックが起こり得ます。
FileMakerのcurlでそのまま参考になりそうな解説は見当たりませんでしたが、とりあえずこの辺でしょうか。
curlコマンドにセッションID(cookie)を指定する方法 · atwata developer blog
http://blog.atwata.com/web/2017/02/08/c … ookie.html
"PHPSSID"はサーバー側がPHPの場合の標準のセッションIDのキー名なので、
サーバー側の実装次第で変わります。
テストしてませんが、こっちも普通のcURL同様の -b をFileMakerはサポートしてるっぽいし、
curl -b "username=abcd; password=efghijkl;"
とかで行けるんでは。
-b で複数cookieが通らなかったら、-H か -header でクエリストリング同様に書いてやる感じでしょうか。
Windowsなので、JSの実行後かどうかまでは考慮せず、単に指定したURLの取得完了のみ判定する場合。
取得したいのがHTMLで書かれているなら、文書の終端にあるはずの</html>が含まれるかで、概ね判断できます。
インターバル入れながらループで</html>を含むかチェックし、
なければ再度待機、あればスクレイピングして次へ、でいけるはず。
HTML以外では、終端判定できるデータパターンがあるか次第。
ただ、Webビューア経由する理由が特に無いのなら、単に「URLから挿入」ステップで良いのでは。
こっちはロード完了待ってからスクリプト進みます。
FileMakerとの連携は事例を知りませんが、FileMaker 16以降なら、原理的にはTwilioでも行けるかも。
https://twilio.kddi-web.com/
通常のcURLと同じ考え方で、ファイルの変わりに変数指定でいけませんか？
curl -c @cookie
とか。
もう恐ろしく古いサンプルで、FileMaker Goのみ想定した作りだったはずですが、
基本の考え方は使えるはずです。
FileMaker Go 単体でお絵かきアプリっぽいことやるテスト
http://filemaker-kou.seesaa.net/article/267153732.html
> javaとかhtmlとか言われると何をどうすればいいのやら。全くわかりません。
JavaScriptとJavaは名前が似ているだけで、別物です。
この辺全くわからないならサンプルがあっても厳しいので、
まずはHTML単体で簡単なお絵かきツールを作れるよう学習してみては？
FileMakerでの検索のように単純ではありませんし、Webの技術的な知識が無いと苦労はしますが、
それぞれの技術はシンプルで、理解できれば大きな広がりもあります。
Web APIとは、粗く言えばプログラム向けのWebサイトです。
所定のURLに「こんなデータをくれ」とリクエストすると、人間用ではなく、プログラム用のデータが返ってくる、というものです。
今の主流は、URL（+JSONやHTTPのヘッダの場合も）という形でリクエストを表現して、
レスポンスはJSONという形式になっているものです。
FileMakerはver.16から、こういったWeb APIがまともに使えるようになりました。
基本は「URLから取得」スクリプトステップと、json関連の関数を使います。
以下はWeb APIの概要とFileMakerの関わりをまとめた資料、及びサンプルです。
■ FileMaker ver.16とWeb API
https://docs.google.com/presentation/d/ … sp=sharing
■ Web API利用のサンプルファイル
https://drive.google.com/open?id=0B-NoW … UpJXzA0RGM
[ Generated in 0.010 seconds, 7 queries executed - Memory usage: 702.43 KiB (Peak: 756.84 KiB) ]