Laboratory of Mobile Agricultural Chemicals Searcher
携帯農薬検索実験室

研究会

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
91 / 114 ﾂﾘｰ <前へ | 次へ>
〔113〕高負荷の要望 s_kobayashi (06/03/19 11:04)
〔132〕Re:テストバージョン s_kobayashi (06/03/30 22:36)
〔135〕専用 CGI 方式 Hidemi Oya (06/03/31 15:43)
〔136〕Re:専用 CGI 方式 s_kobayashi (06/04/02 19:08)
〔137〕Re:専用 CGI 方式 Hidemi Oya (06/04/03 13:22)
〔138〕スクリプトファイルの文字コード Hidemi Oya (06/04/03 22:23)
〔139〕Re:スクリプトファイルの文字コード s_kobayashi (06/04/06 6:56)
〔140〕Re:スクリプトファイルの文字コード Hidemi Oya (06/04/07 1:17)
〔141〕Re:スクリプトファイルの文字コード s_kobayashi (06/04/07 21:15)
〔132〕Re:テストバージョン
 s_kobayashi  (06/03/30 22:36)
引用なし
   ＞Hidemi Oyaさん
>s_kobayashiさん、こん＊＊は。Hidemi Oya です。
>
>　<a href="http://macs.o-ya.net/perl/test/">テストバージョン</a>に、適用表の最初の「農薬の種類」「農薬の名称」のリンクにジャンプすると、種類あるいは名称以外の条件を全てリセットして、その種類あるいは名称の全農薬を再検索する機能を追加してみましたので、お試しください。再検索前の農薬の総数(分類名の右側に表示されています)だけ覚えておけば、再検索後の総数との比較で、違いがあるかどうかは判断できます。現在のプログラム構造でできるのは、ここまでです。

試作ありがとうございます。かなり私のイメージに近いです。

>>連続的な操作であれば、再検索結果の商品名リストと当初結果商品名リストが同じか違うかくらいはperlが教えてくれてもいいかなと思います。

もしも今回提案されたリセット・再検索機能をformのボタンで処理すれば、もう一度cgiに引数を渡し直せますよね（リンクでもキー名と内容を列記すれば可能？）。cgiに現在の薬剤数を渡せれば、ほとんどプログラムを変更しなくても当初の薬剤数と再検索結果と同じか違うかを結果で示すことは可能かもしれません。

>　今のところ ver3.x がリリース候補のまま止まっており、私にはこちらの完成の方が優先事項になります。ということで、お望みの機能が必要なら、ぜひ s_kobayashi さんに開発をお願いしたいのですけど…。

うーん。とりあえず、自分のサーバーでテストバージョンを動かしてみないと何とも言えませんけれど。考えさせてください。
〔135〕専用 CGI 方式
 Hidemi Oya WEB  (06/03/31 15:43)
引用なし
   s_kobayashiさん、こん＊＊は。Hidemi Oya です。

>試作ありがとうございます。かなり私のイメージに近いです。
　Google 検索にリンクさせてた部分を vtllg303.do の呼び出し用にリンクを張り替えただけなので、この程度ならお安いご用です。ただ、この方法では、他の農薬の適用を確認するのが面倒になるので、決して実用的ではありません(^_^;)。

>もしも今回提案されたリセット・再検索機能をformのボタンで処理すれば、もう一度cgiに引数を渡し直せますよね（リンクでもキー名と内容を列記すれば可能？）。
　URL リライト方式でも、FORM でやっていることと実態としては同じです。URL リライトの方が端末側の受信量を削減できるため、当サイトの検索システムでは文字入力以外では FORM の使用を避けています。

>cgiに現在の薬剤数を渡せれば、ほとんどプログラムを変更しなくても当初の薬剤数と再検索結果と同じか違うかを結果で示すことは可能かもしれません。
　農薬グループ展開や有効成分名による再検索のように現在のメイン CGI 内に組み入れるのではなく、Google 検索の実行と同様に別の専用 CGI を作成し、そちらを呼び出すようにすれば、薬剤「数」だけでなく、薬剤「名」の比較も可能ですね。数だけ比較しても登録内容が異なる農薬があるかないかが分かるだけで、具体的な薬剤名が分からないならあまり用をなしません。この方法を採るなら、やはり薬剤名の比較までやるべきでしょうね。
　また、この方法なら、メイン CGI の検索条件等はリセットされないので、戻ってきて他の農薬の適用を確認するような場合も実用的です。有効成分名による再検索も、こちらの方法で実装した方が使いやすそうですね。

>うーん。とりあえず、自分のサーバーでテストバージョンを動かしてみないと何とも言えませんけれど。考えさせてください。
　上記のように別個の専用 CGI を呼び出す方式なら、パラメータとして作物コード／病害虫コード／病害虫名／農薬名を受け取って、
(1) 全条件を指定して vtllg303.do を実行し、結果をメモリに保存
(2) 屋号なし農薬名だけを指定して vtllg303.do を実行し、結果をメモリに保存
(3) (1) と (2) の結果を比較して異なる部分を出力
という CGI を作成すれば OK です。パラメータ受け渡し方法だけ決まっていれば、あとはこちら側で Google 検索機能のように必要なパラメータを設定してその CGI を呼び出すだけですから、お互いに相手のシステムを気にすることなく開発は可能です。

　当サイトの検索システムは、検索条件や検索結果をセッションデータに保存しているので、当システムのセッションデータを利用可能なアドオン CGI にすれば、検索回数や受け渡しパラメータ数の削減が可能になります。が、現状ではアドオン CGI を実装できるような構造にはなっていないので、すぐに採用できる方法ではありません。
　てことで、上記のような専用 CGI を連携させる方式での開発分担でいかがでしょう？
〔136〕Re:専用 CGI 方式
 s_kobayashi  (06/04/02 19:08)
引用なし
   ＞OhYeah!さん

>　当サイトの検索システムは、検索条件や検索結果をセッションデータに保存しているので、当システムのセッションデータを利用可能なアドオン CGI にすれば、検索回数や受け渡しパラメータ数の削減が可能になります。が、現状ではアドオン CGI を実装できるような構造にはなっていないので、すぐに採用できる方法ではありません。
>　てことで、上記のような専用 CGI を連携させる方式での開発分担でいかがでしょう？

　とりあえず、version2.5.2を見ながら流れを確認してみます。

　人それぞれやり方があるので、OhYeah!さんのやり方と自分のやり方を見比べながら、すりあわせていく方が良いかなと思っています。とりあえずは自分の得意なやり方で作ってみて、徐々にOhYeah!さんのやり方を取り入れて、モジュールなどを合わせていくという感じです。

　2.5.2では、改行コードが\r\nのplスクリプトがありましたが、何か理由があるのでしょうか。linuxでの動作を前提にするのなら、\nでいいと思うのですけれど。。


私のやり方では、
・取り込みはLWP::SimpleかWWW::Mechanize
・文字コードは基本的に use encoding "euc-jp"
・ヘッダはprint文に直書きもしくはCGIモジュール

と非常に雑ぱくです。(^◇^;)

vtllg303.do を呼び出してみたりして、挙動を確認してみようかと思います。あんまり期待しないでくださいね。(^^ゞ
〔137〕Re:専用 CGI 方式
 Hidemi Oya WEB  (06/04/03 13:22)
引用なし
   s_kobayashiさん、こん＊＊は。Hidemi Oya です。

＞OhYeah!さん
　すみません。ここでは Hidemi Oya なので、よろしくお願いします。

>　人それぞれやり方があるので、OhYeah!さんのやり方と自分のやり方を見比べながら、すりあわせていく方が良いかなと思っています。
　将来的にアドオン CGI にするならすりあわせが必要になりますが、当面は好きなやり方でやってください。s_kobayashi さんのサーバで CGI を走らせてもらえば、XREA の仕様に合わせる必要もありませんし。
　ただし、完全にそちらの CGI に移ってしまいますから、結果出力に関しては機種依存しないようなフォーマットにするか、機種別に変えてもらう必要があります。もし機種別に出力を変えるなら、実験成果にある機種判定ルーチンを利用していただいて結構です。

>　2.5.2では、改行コードが\r\nのplスクリプトがありましたが、何か理由があるのでしょうか。linuxでの動作を前提にするのなら、\nでいいと思うのですけれど。。
　う〜ん、保存するときに改行コードを変更し忘れてたかな(^_^;)。

>・文字コードは基本的に use encoding "euc-jp"
　内部文字コードはお好きなものをご利用ください。携帯電話での利用を考えると、出力は ShiftJIS が必須になります。
　薬検出力の UTF-8 は MS 体系なので、encoding モジュール(実質 Jcode)とは特殊文字のマッピングが若干異なり、cm, u などが正常に変換できません。ただ、農薬名には〔〕くらいしか特殊文字が含まれていないので、encoding モジュールでも恐らく大丈夫だと思います。
　当サイト検索システムの開発に当たって各種文字コード変換モジュールを試したのですが、最終的に Unicode::Japanese モジュールのみの対応としたのは、MS 体系との親和性によるものです。Unicode::Japanese は携帯電話の絵文字にも対応していますが、こちらは使用していません。

> vtllg303.do を呼び出してみたりして、挙動を確認してみようかと思います。あんまり期待しないでくださいね。(^^ゞ
　呼び出し方は [#129] を参照してください。[#129] に書いたパラメータで、条件指定に使用しないパラメータは、全て "" (ヌルストリング)で OK です。ただし、currentPage は "1" を設定する必要があります。
〔138〕スクリプトファイルの文字コード
 Hidemi Oya WEB  (06/04/03 22:23)
引用なし
   s_kobayashiさん、こん＊＊は。Hidemi Oya です。

>>・文字コードは基本的に use encoding "euc-jp"
>　内部文字コードはお好きなものをご利用ください。携帯電話での利用を考えると、出力は ShiftJIS が必須になります。
　薬検の出力が UTF-8 なので、もしテーブルの判定にキャプションの「登録農薬一覧」という文字列を使うとすれば、内部文字コードは UTF-8 の方が良いですね。EUC だと、UTF-8 → EUC → ShiftJIS と２回変換が必要になり、無駄に CPU タイムを消費します。encoding を使用する場合の perl 側の内部コードも UTF-8 が標準ですし。
　ただし、perl 5.8 系は BOM 付き UTF-8 のファイルだと使えないので、使用できるエディタが限られるかもしれません(最近は結構対応してるのかな？)。私が愛用している JmEditor2 は、BOM 無しの UTF-8N に対応しています。
〔139〕Re:スクリプトファイルの文字コード
 s_kobayashi  (06/04/06 6:56)
引用なし
   ＞Hidemi Oyaさん

>　ただし、perl 5.8 系は BOM 付き UTF-8 のファイルだと使えないので、使用できるエディタが限られるかもしれません(最近は結構対応してるのかな？)。私が愛用している JmEditor2 は、BOM 無しの UTF-8N に対応しています。

私は自宅の fedora core3 サーバーにssh経由でスクリプトを書くことが多いので、mifes for linux を使っています。サーバーはi18nで文字コードをeucJPにしているので（このあたりが失敗かも？）、スクリプト、csvデータなどもできるだけeucで管理しています。もちろん、相手のhtmlデータによってはsjisやutf-8などを吸い込んだりしますけれど、出力はhtmlも含めてeucで行っています。私のauの場合は、htmlヘッダでeucを指定しておけば、特に文字化けもせず安定して利用できています。

ともあれ、自分の得意なやり方で動くスクリプトを書けるようになるのが先決ですね。(^^ゞ
〔140〕Re:スクリプトファイルの文字コード
 Hidemi Oya WEB  (06/04/07 1:17)
引用なし
   s_kobayashiさん、こん＊＊は。Hidemi Oya です。

>私のauの場合は、htmlヘッダでeucを指定しておけば、特に文字化けもせず安定して利用できています。
　au の場合、プロクシが HTML を WML に変換する際に、併せて文字コード変換もしているからだと思います。確か、i-mode の絵文字を au 用に変換することまでやってたような気がします。vodafone の新しい機種では、端末単体で EUC や UTF-8 が使えたりします。
　が、au, vodafone 以外の機種、あるいはやや古い機種の存在を考えると、現状で最も無難な選択肢は ShiftJIS しかありません。文字コードや使用する HTML 要素は、少なくとも３年、できれば５年以上前の機種を対象として検討した方が、皆さんが幸せになれます。
〔141〕Re:スクリプトファイルの文字コード
 s_kobayashi  (06/04/07 21:15)
引用なし
   ＞Hidemi Oyaさん

>　が、au, vodafone 以外の機種、あるいはやや古い機種の存在を考えると、現状で最も無難な選択肢は ShiftJIS しかありません。文字コードや使用する HTML 要素は、少なくとも３年、できれば５年以上前の機種を対象として検討した方が、皆さんが幸せになれます。

　sjisに対応するだけならそれほど難しくありませんね。
　自宅サーバーの不調が直ったらチャレンジしてみます。
  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
91 / 114 ﾂﾘｰ <前へ | 次へ>
ページ：  ┃  記事番号：   
(SS)C-BOARD vv3.8 is Free.